Re: Check for revocation certificates before running apt-get?
Paul Wise:
> On Sun, Dec 15, 2013 at 11:15 AM, adrelanos wrote:
>
>> I can try that. Should that become a separate package or part of, well
>> apt-get? It would probably just be three files, a config file, an
>> /etc/apt/apt.conf.d/ config fragment and a bash script.
>
> I'm guessing the apt package would be the place to put it.
I am wondering how excited the apt developers would be about adding a
bash script to their app. I'll see how far I get and contact them when
there is something to talk about.
> My initial thought would be that the implementation when run from the
> apt hook would go through all the trusted keyrings and fetch the keys
> from each of them from the default keyservers in GPG.
Imagine for a moment, you would like my implementation... Then, would
you suppose to activate this by default in Debian?
In that case, can the keyservers handle the load from the mass of Debian
and its derivatives users? Should we ask keyserver operators or on gnupg
mailing list if that is a fine idea?
That was the reason for my proposal using http. I forgot to add, that I
planed to do that to reduce load from the keyservers. For Whonix I'd
like to activate this feature by default. If keyservers are capable and
willing to take the load is still unknown. But at least sourceforge does
not pose any traffic limitations.
When keyservers don't mind, great, will make the implementation simpler.
> /etc/apt/trusted.gpg
> /etc/apt/trusted.gpg.d/*.gpg
> That would probably be fine for most Debian users but at that point I
> remembered that the Riseup OpenGPG best practices document has
> something to say about keyring refreshes;
> that keyring refreshes
> should happen using parcimonie to make correlation attacks harder.
parcimonie hides keys you have in your keyring. Personal contacts.
That's worth hiding. If all Debian users were to always automatically
check if the official singing key has been revoked, that wouldn't be a
secret worth to hide.
[Routing that traffic over Tor such as having an .onion apt mirror is a
different discussion we had on this list a while ago.]
> This would especially be a problem for folks with multiple PPAs in
> their apt trusted keys.
What PPAs you're using isn't a secret anyway, since apt traffic isn't
encrypted. If you want to hide which PPAs you're using and which signing
keys you're refreshing, I think it's best to route all that traffic over
Tor. I don't understand the benefit in selectively routing key fetches
of signing keys over Tor while leaving the rest in the clear.
> https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#make-sure-you-are-receiving-regular-key-updates
>
> That complicates things but would probably still be doable, thoughts:
PPA users are another reason for having a modular /etc/apt-revok.d/
config folder. In future, the add-apt-repository tool or the ppa-package
itself could drop a configuration snippet in that folder.
parcimonie is great. These tools could complement themselves. But they
have different purposes. parcimonie keeps your keyring current by
refreshing the keys at random times from the key server [over Tor].
apt-key-revok-check however would check for revoked apt keys every time
[or configurable, only once per day or x] right before running apt-get
update.
> Add a system daemon for parcimonie
But parcimonie already has a system daemon?
> that refreshes the apt keyring when
> tor & network is available.
I don't know if parcimonie can be configured to refresh the apt keyring.
Would probably be worth a feature request. I am not skilled to add such
a feature to parcimonie. That feature should however be completely
unrelated to what we're discussion here.
> Add an apt hook that refreshes trusted.gpg keyrings in /etc have not
> been touched recently (so it works when parcimonie or another refresh
> mechanism is not being run) and also checks all keyrings for revoked
> keys and
I don't think I can integrate with parcimonie, since I don't speak perl.
> reports them to the user.
I can write a nice cli app safely doing the key fetching before running
apt-get. And also maybe also add hooks for certain events aka
"revocation certificate found". So other root users can drop
configuration snippets to /etc/apt-revok.d/ and define scripts which get
run upon certain events. One may add a mail notification, someone else
can add zenity popup or else.
Even without notification. Should a revocation certificate get imported,
apt-get will tell them, that the apt signing key is no longer valid anyway.
Reply to: