2016-02-27 20 views
5

OSX El Capitan e Go 1.6OSX: Codice-sign eseguibile per evitare warning firewall dialogo

Quello che voglio è più semplice di quanto sembri a partire dal titolo.

Il firewall OSX non consente a nessuna applicazione sconosciuta di accettare connessioni. All'avvio di qualsiasi programma di questo tipo, all'utente viene presentata una finestra di dialogo indipendentemente dal fatto che il suddetto eseguibile debba essere autorizzato a ricevere connessioni. La scelta dell'utente viene quindi ricordata.

Quanto sopra funziona bene quando, ad esempio, si sviluppa con nodo in cui l'eseguibile corrente è un singolo binario e l'utente deve solo consentirlo/negarlo una volta.

Quando si sviluppa in go (e in qualsiasi altro linguaggio compilato) l'eseguibile creato è diverso ogni volta. Il che significa che ottengo la finestra di dialogo ogni volta che avvio il mio server.

Un modo per evitare questa finestra di dialogo è firmare l'eseguibile con un certificato autofirmato che uno genera in OSX stesso. Una volta ottenuto il certificato, firmiamo semplicemente l'eseguibile e lo permettiamo/neghiamo una volta. Le firme di codice vengono sempre ricordate anche se il binario eseguibile cambia.

Quindi, la mia domanda è:

C'è un modo per rendere go eseguire il comando firma prima di eseguire il binario compilato?

risposta

3

Sciocco. Mi ci sono voluti 5 minuti per scrivere la domanda e 2 minuti per trovare la risposta e scrivere la sceneggiatura che la risolve. Lo posterò qui nel caso in cui qualcuno inciampi sullo stesso problema.

binary=$GOPATH/pkg/kliron/hiss/hiss.a 
go build -o $binary hiss/main.go 
codesign -f -s klironCode $binary --deep 
$binary "[email protected]" 

Basta usare go build.

6

Ancora più facile: avviare il server in modo esplicito su localhost, come:

http.ListenAndServe("localhost:8080", nil) 

ho scritto un piccolo pezzo su questo recente:

suppressing-accept-incoming-network-connections-warnings-on-osx

+0

Nizza, grazie per la condivisione. Tuttavia, a volte è necessario ascoltare l'interfaccia esterna, ad esempio, per testare gli schemi di autenticazione OAuth2 o interagire con altri servizi online. Certo, potresti indirizzare il tuo hostname a localhost in/etc/host e sarebbe tutto ciò che è necessario per alcuni (ad esempio oauth) ma non tutti i casi. – kliron

+0

/etc/host ->/etc/hosts – kliron