// comunidad de visitantes y creadores
Una sección viva para saber qué se revisa antes de recomendar una app, cómo valorar guías y qué canales económicos usar para avisos sin spam.
La página de Open Source deja constancia del origen del APK, el repo que lo respalda y el estado público de su última verificación.
Las guías se organizan por problemas reales de visitante: claves, APK, privacidad, build de clima y conversiones de freelance.
CodeHub no envía notificaciones generales todas las semanas. El canal de avisos se reserva para releases relevantes, incidentes y cambios de seguridad.
CodeHub acepta reportes de seguridad con el mismo criterio de verificación que el catálogo. No publiques detalles explotables en foros públicos antes de una corrección.
Contacto: wilson.e360labs@gmail.com. Respuesta esperada en un plazo razonable según la carga del proyecto.
La página de Open Source se construye con fichas revisables, no con marketing estático. Esto es lo que se entiende por “verificado”:
| Sello | Significado | Limitación importante |
|---|---|---|
| Verificado | El enlace, la licencia y el release visible apuntan al mismo proyecto. | No sustituye una auditoría de seguridad del código. |
| Revisado | Fuente y checksum validados parcialmente; aún en control manual. | Puede cambiar de estado entre revisiones. |
| Externo | Se enlista por transparencia, pero se advierte que requiere revisión del usuario. | No se garantiza la seguridad del APK. |
La palabra «verificado» se usa mucho y significa poco. Aquí está el procedimiento concreto que sigo para que el sello diga algo comprobable, y también dónde llega ese procedimiento y dónde se queda corto. Está escrito así para que cualquiera pueda discutirlo, no para que se acepte por fe.
Antes de mirar el APK miro el repositorio. Un proyecto que no tiene repositorio público no entra, aunque su APK funcione perfectamente. La razón no es ideología: es que sin código revisable no hay manera de distinguir una app legítima de una que exfiltra datos, y yo no puedo poner mi nombre delante de algo que no pude leer.
Una vez dentro del repositorio reviso cuatro cosas. Que el paquete declarado en el manifiesto coincida con el del proyecto original — un nombre de paquete distinto es la señal más clara de una reempaquetación. Que la licencia esté presente y sea una licencia real, no un archivo vacío. Que haya actividad reciente: commits, issues abiertos y cerrados, respuesta del autor. Y que el proyecto tenga un README que describa lo que hace sin prometer lo que no hace.
El APK debe venir de los Releases del mismo usuario u organización. No de un espejo, no de un acortador, no de un archivo subido a un servicio de nube por una cuenta anónima. Si el proyecto publica checksum o firma, lo comparo; si no lo publica, lo anoto como una limitación de la ficha en lugar de fingir que la verificación ocurrió.
También comparo el historial de versiones. Un salto de versión sin tag correspondiente, o un Release cuyo artefacto pesa mucho más que el del proyecto anterior sin cambio de dependencias, es algo que conviene mirar antes de recomendar.
Leo el manifiesto y pregunto por cada permiso: ¿esta app lo necesita para lo que anuncia? Una linterna que pide contactos no tiene explicación legítima. Una app de notas con permiso de red debe justificar por qué sincroniza, y si no lo explica, la ficha lo dice.
Este es el paso más lento y el que más aporta. También es donde está el límite honesto del sello: no hago análisis dinámico ni pruebas de tráfico. No instrumento la app en un dispositivo de prueba para ver qué dominios consulta. Lo que el sello afirma es lo que pude comprobar leyendo y contrastando fuentes, y esa distinción está escrita en la tabla de la sección anterior.
Tres motivos, y los publico como aviso cuando afecta a quien ya la tenía instalada. Primero, que el repositorio cambie de dueño o desaparezca, porque entonces ya no hay fuente que respaldar. Segundo, que aparezca un Release cuyo artefacto no coincide con lo publicado. Tercero, que el proyecto empiece a distribuirse por canales paralelos con builds distintas, lo cual rompe la trazabilidad por completo.
Retirar una app no es un castigo al proyecto: es que dejé de poder verificarlo. Si el autor recupera el repositorio y publica con trazabilidad, la ficha vuelve con una nueva fecha de revisión.
No certifica que la app sea segura. No sustituye una auditoría de seguridad del código. No garantiza que el proyecto se mantenga. Y no convierte la instalación fuera de Play en algo sin riesgo: quien instala un APK de terceros asume ese riesgo aunque el catálogo lo haya revisado. Si buscas certeza absoluta, esta no es la sección adecuada; si buscas un criterio público, reproducible y escrito, esta sí lo es.
Dudas sobre un sello concreto: escríbeme a wilson.e360labs@gmail.com indicando la app y qué parte quieres que justifique. Si encontraste una vulnerabilidad, el canal de reportes está en la sección superior.