El estado de los proyectos
Los viejos proyectos populares, que ya no se mantienen y se olvidan, a menudo se pueden usar como un vector para propagar virus si alguien puede comprometer la cuenta y cargar una nueva versión compilada. Lo mismo se ha hecho a menudo con los sistemas de actualización automática, incluso peor, ya que se entregarán ellos mismos y, a menudo, instalarán una actualización en los sistemas de los usuarios sin que el usuario final lo sepa.
Posibles acciones a tomar
Mantenedores y desarrolladores
Puede intentar ponerse en contacto con los desarrolladores / mantenedores, pero si es un proyecto antiguo, es poco probable que respondan. Si su cuenta se ha visto comprometida, entonces les avisarás o les gritarás en la pared.
Plataforma / Red de entrega
Puede tener una mejor oportunidad de eliminar el código malicioso contactando a la plataforma que aloja el software. Yo mismo no he intentado contactar directamente con una plataforma como Sourceforge o NPM. La probabilidad de que reciba una respuesta a menudo está relacionada con el tamaño del negocio y si se ha monetizado, si se trata de un espectáculo de una sola persona, ¡buena suerte!
Cuanta más información tenga para verificar su solicitud de eliminación, más probable y rápidamente debería suceder.
La comunidad y tu voz
A menudo, puede intentar los pasos anteriores y llegar aquí sintiéndose impotente, pero si puede dejar un comentario o una revisión sobre el software, eso puede ser lo mejor que puede hacer. Aunque muchos usuarios finales seguirán descargando el software a ciegas o antes confían en el software.
Extra: Prevención reciente y futura
Deja de leer aquí ™ o continúa ¯\_(ツ)_/¯
Hubo un paquete NPM muy utilizado con el que se hizo el responsable original, ya que muchos proyectos de código abierto alcanzan en su ciclo de vida. Alguien extendió la mano pidiendo mantenerlo. Seguramente esto debe sentirse como una carga molesta levantada de los hombros de un desarrollador. Desafortunadamente, el nuevo responsable lanzó malware para robar billeteras criptográficas .
Irónicamente, escuché esto de boca en boca y leí el problema abierto en el repositorio de github antes de leer un artículo al respecto o verlo aparecer en el npm audit. Esto demuestra que su voz en una plataforma pública realmente puede tener un impacto .
Nuestro grupo de reunión tuvo una charla rápida sobre lo que la comunidad podría hacer para evitar tal cosa, y de quién es la responsabilidad de evitar que eso suceda.
Plataforma / Red de entrega
Hacer que sea responsabilidad de npm requeriría una situación monetaria en el lugar que apestaría, o tal vez solo estaría disponible para las empresas, pero ¿entonces todos los demás se beneficiarían de forma gratuita?
Fuente de mantenimiento
Como mantenedores de código abierto, debemos ser conscientes de las consecuencias de nuestras acciones. Si ha sido un mantenedor de código abierto, puede convertirse en una tarea difícil a medida que disminuye el valor intrínseco que obtiene del proyecto. Sería difícil decir no a alguien que aparentemente tiene la energía que una vez tuvo para mantener su proyecto en marcha. Una cosa a tener en cuenta es que algunas plataformas permiten un proceso de revisión antes de publicar si los niveles de permisos correctos están en su lugar. En este caso, la propiedad del proyecto se entregó por completo, debe tratar de no hacerlo a menos que confíe absolutamente en la persona / entidad, incluso aunque parezca que no es una forma limpia de llevar a cabo la continuación del software establecido y confiable. La gente también podría hacer sus tenedores de código, pero eso puede ser complicado.
Comunidad y consumidores
La infraestructura actual podría usar algunas funciones para ayudar.
Por ejemplo, los lanzamientos pueden ser verificados, aprobados o marcados por la comunidad, al igual que los torrentes pueden ser evaluados por la comunidad para que otros puedan tomar decisiones rápidas antes de dar el paso. Una calificación negativa alta podría marcar un paquete y advertir a los consumidores acerca de él y futuras instalaciones.
Como consumidor que instala ciegamente software y lo actualiza, es su responsabilidad vigilar lo que está consumiendo. Puede usar gestores de paquetes que tengan bloqueado la versión para ayudar a negar esto. Lamentablemente, dudo que muchas personas pasen el tiempo necesario para revisar los cientos de paquetes que están instalando cuando establecen un good'ol npm install. Algunas empresas pasan por un proceso de proveedor cuando cambia el software; Espero que ninguna empresa haga esto para los paquetes NPM (podría detener seriamente el desarrollo), pero esta fue una opción presentada.
Dinero $$$
Nadie quiere pagar por el software gratuito de código abierto, pero si aquellos que escriben código fueron recompensados por sus contribuciones, pueden estar más motivados para mantener su software y su imagen comunitaria. El dinero podría provenir directamente de los consumidores o como un goteo para la plataforma en la que se entrega. Por mucho que odie verlo, podría ver bibliotecas que siguen el mismo camino que las plataformas de CI, gratuitas para código abierto pero de costo privado / comercial, esto podría manejarse con licencia, pero los desarrolladores no quieren perder el tiempo convirtiéndose en licencias de profesiones tampoco (tal vez podrían ser simplificadas y directas).