Come posso verificare che un pacchetto di grandi dimensioni in un repository git sia sicuro?

Sto esaminando specificamente emacs helm , che ha le seguenti proprietà:

ha migliaia di commit
è in gran parte gestito da un utente
il manutentore non ha altri profili (social media, ecc.) che sono riuscito a trovare in alcune ricerche
è attivamente mantenuto (oggi)

Dal momento che sto per installare codice arbitrario sul mio computer da utilizzare nel mio editor di testo, ho voluto verificare se questo ha subito un processo di revisione. Vorrei dire "beh, è open source" ma sono davvero lontano dalla capacità elisp di controllare tutto il codice da solo. Vorrei presumere che altri membri della comunità lo abbiano esaminato, ma uno probabilmente è falso e due ci sono impegni aggiornati. Ci sono altre strategie che mi mancano?

Per la cronaca, il vettore è semplice: "open source" non ha molta importanza se il contributore lavora con un account usa e getta o se non esiste un processo di revisione.

— djechlin
fonte

" Verifica " è una parola grossa. Nel senso regolare della parola, penso che la risposta sia: "Non puoi (non puoi)". Puoi seguire l'attività di sviluppo di una biblioteca e puoi controllare le firme digitali e simili, ma non c'è nulla di sicuro e certo, credo.

— Estratto il

Buona domanda. FWIW, il codice fornito con Emacs viene esaminato (tramite la mailing list di emacs-diffs), ma se un collaboratore dovesse aggiungere una falla nella sicurezza, sono sicuro che sarebbe in grado di farlo senza essere notato. Naturalmente, sarei sorpreso se in Emacs non ci fossero già molte grandi falle accidentali di sicurezza, quindi non sono sicuro di quanto possa essere un problema. Quindi penso che per essere in grado di ottenere una risposta più rassicurante, è necessario concentrarsi su specifiche minacce semplici (ad esempio, dovrebbe essere abbastanza facile verificare se il codice esegue una sorta di sorveglianza non nascosta).

— Stefan,

Il manutentore è attivo per molti anni su emacs devel, che può essere verificato con una ricerca, quindi questa è una garanzia: lists.gnu.org/archive/cgi-bin/…

— Tom

@Stefan, stavo pensando solo a un controllo a campione. Dal mio punto di vista, mapatomspotrebbe essere inserito nel gruppo "pericoloso" insieme a start-process, evale funcall. Naturalmente ci sarebbero alcuni falsi positivi, ma se il pacchetto non utilizza nessuna di quelle funzioni, può essere contrassegnato come innocuo con grande certezza.

— abo-ABO

È necessario aggiungere il nuovo make-process, così come call-process, dbus-<foo>, make-network-stream, e poi vc-do-command, vc-git-command, .... E se si mette evale funcallnella categoria "pericoloso", allora la maggior parte / tutti i pacchetti sono pericolosi.

— Stefan,

La risposta breve è a meno che tu non legga tu stesso il codice che stai prendendo molto sulla fiducia. Detto questo, fidarsi di un progetto proveniente da un SCM a monte è un po 'più sicuro di uno che è stato estratto direttamente dal Wiki di Emacs, ad esempio. Tuttavia, fondamentalmente, ti fidi dell'autore del pacchetto di non trasformare il male e di abusare della possibilità di eseguire codice arbitrario durante la tua sessione di Emacs.

Ci sono alcune cose che potrebbero farti sentire più sicuro:

Attenersi ai pacchetti più diffusi

Mentre i pacchetti popolari non ricevono automaticamente più recensioni, il fatto che abbiano più utenti significa che aumentano le possibilità che vengano rilevati comportamenti dannosi prima che ciò influisca.

Guarda le metriche del codice

Su github puoi avere una visione abbastanza buona della cronologia dei contributi del progetto. Anche se l'autore principale fa in modo che la maggior parte dei commit con una vasta gamma di autori mostri che ci sono altre persone con un interesse attivo per la stabilità e l'efficacia del codice.

Preferisce GNU ELPA e MELPA Stable ai repository che tengono traccia di HEAD (MELPA) o consentono invii non controllati (Marmellata)

Mentre vivere sul filo del rasoio ha un certo fascino per coloro che desiderano le ultime funzionalità brillanti, significa che potresti essere il primo ad accettare l'ultimo commit nel tuo ambiente. Anche se non malevolo, potresti ottenere un pacchetto in uno stato di flusso mentre una versione "ufficiale" avrà almeno una sorta di revisione superficiale. Ad esempio, i pacchetti ELPA GNU verranno impegnati solo da quegli utenti emacs-devel con diritti di commit.

Alla fine sono sicuro che ad un certo punto ci sarà una violazione della sicurezza tramite il sistema di pacchetti, anche se è solo un esperimento di prova del concetto. Questo sarà il punto in cui potresti dover fare affidamento sui tuoi backup regolari.

— stsquad
fonte

Marmalade è un povero archivio quando si tratta di "fiducia". Permette a chiunque di caricare qualsiasi pacchetto con qualsiasi nome, senza verifica o revisione. E non è esattamente ben mantenuto (basta guardare il numero di problemi aperti).

— lunaryorn,

@lunaryorn: buon punto, modificherò la risposta.

— stsquad,

@lunaryorn MELPA ha ancora più problemi aperti rispetto al repository elmarmalade, quindi dubito che questa sia una metrica utilizzabile.

— Wasamasa,

@stsquad L'unica cosa che ti dà MELPA Stable sono le versioni taggate di cose che sarebbero comunque finite in MELPA, quindi non vedo quanto sia più sicuro dell'uso di Marmalade.

— Wasamasa,

@wasamasa Siamo spiacenti, il mio commento è stato espresso male. Il numero non dice molto, di sicuro, ma le questioni aperte sono dicendo: Non c'è reazione pari a zero sulle nuove emissioni, nessun commento, nemmeno etichette o assegnazioni. La marmellata d'arance è effettivamente morta.

— lunaryorn,