[Dev] Bug #567 has significant security impact on binaries

fauno fauno at endefensadelsl.org
Sat Jun 27 16:39:58 GMT 2015


Luke <g4jc at openmailbox.org> writes:

> On 06/27/2015 12:11 PM, fauno wrote:
>> Michał Masłowski <mtjm at mtjm.eu> writes:
>>
>>>> The package will be compiled, and immediately signed with the packager's
>>>> key during compile process.
>>> This isn't nice for batch builds: user leaves the computer building for
>>> hours, then runs librerelease, inputs the GPG passphrase for pinentry,
>>> gpg-agent will cache it for a short time.
>> right, this was the initial decision for putting signing on
>> librerelease.  security-wise having to put the signature for
>> each batch/unnatended build is bothersome but necessary.
> If this is actually an issue, it is described in the manpage for gpg-agent.
>
> nano ~/.gnupg/gpg-agent-conf
> set default-cache-ttl and max-cache-ttl as needed.
> I would suppose a simple bash script could also be made that looks for
> the makepkg process. If it still exists, increase time-to-live in
> gpg-agent by x-seconds.
> This is still better than signing long after the package has been built.

i think you need to restart the agent to change the ttl.

what if there's an intermediary signature that only libremakepkg can
issue and then librerelease verifies this and signs with the packager
key?



-- 
http://vqfe4xmhxzi7w2uv.onion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 584 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20150627/52aa3463/attachment.sig>


More information about the Dev mailing list