Re: Check for revocation certificates before running apt-get?
Paul Wise:
> On Sat, Dec 14, 2013 at 6:47 AM, adrelanos wrote:
>
>> is it possible to hook apt-get somehow to do some action done before
>> apt-get starts any network activity?
>
> Based on a quick grep of the apt package, APT::Update::Pre-Invoke
> might be what you want.
That seems perfect.
> Here is an extremely dangerous example of how it can be used:
>
> http://www.webupd8.org/2009/06/automatically-import-launchpad-ppa-keys.html
>
> It would be possible to do it in a secure way but that example is
> definitely not secure.
I agree it's not secure. Ubuntu PPA's do teach users download keys
without any verification. That is worrying but another story.
>> I would like to add refresh gpg keys from a server first to check if any
>> of them have been revoked in meanwhile.
>
> That sounds like a useful feature to have.
Thanks.
> When you implement this, please ensure it isn't vulnerable to any
> duplicate-keyid problems:
>
> http://debian-administration.org/users/dkg/weblog/105
Damn, I wasn't aware of the latest news that long key ids are now also
insecure. Thank you for educating me.
>> (I am asking this because I would like to add such a feature to Whonix,
>> which is a derivative of Debian. Hope you don't mind me asking here.)
>
> I would encourage you to get that (or a background cron job) into
> Debian instead, it is a pretty important security enhancement IMO.
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 would implement it as a bash script (since I am not capable of any
other language). How to name it? apt-key-revocation-check? I am happy
about better suggestions.
The bash script would source the configuration folder /etc/apt-revok.d/
for bash configuration fragments in lexical order. That way Debian could
ship their config /etc/apt-revok.d/20_debian and derivatives could just
drop in their extra config on top of that.
The config file would contain one or multiple links on http servers.
Download would happen over http.
Example, /etc/apt-revok.d/30_whonix could contain:
aptrevok_linklist+="
http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/aptrevok/revocation-file
"
apt_revok_key_folders+=" /usr/share/whonix/keys/whonix-keys.d "
apt-key-revocation-check would then download
http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/aptrevok/revocation-file
and
http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/aptrevok/revocation-file.asc.
Import all keys stored inside the /usr/share/whonix/keys/whonix-keys.d
folder into a temporary gpg directory and check if revocation-file can
be verified. If yes, import it into apt-key.
I could even add config options what should happen if no remote page can
be reached or add hooks for pre-fetch, post-fetch, found-revok
certificate, found-no-revok certificate etc.
And if you're not sure if it's worth to mentor me on this, you can check
out some of my related work. [1] [2] [3]
Cheers,
adrelanos
[1] https://github.com/Whonix/Whonix
[2]
https://github.com/Whonix/Whonix/blob/master/whonix_shared/usr/bin/whonix_repository
[3]
https://github.com/Whonix/Whonix/blob/master/man/whonix_shared/whonix_repository.8.ronn
Reply to: