[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Check for revocation certificates before running apt-get?



Paul Wise:> On Mon, Dec 16, 2013 at 1:34 PM, adrelanos wrote:
>
>> 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.
>
> I suppose POSIX shell would be preferable.

I always hoped there is no holy war sh vs bash and never found any
existing discussions. Could you point me to these please if they exist?

I for one preferred bash over sh with my, perhaps naive, "why bother
with sh when you can use its successor that is even an essential package
in Debian" view.

Hopefully implementing this in bash instead of sh isn't a deal breaker?

>> Imagine for a moment, you would like my implementation... Then, would
>> you suppose to activate this by default in Debian?
>
> Not sure, but the feature should at least be present even if it is
> disabled by default...
>
>> 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?
>
> Zero idea, best ask indeed.

Asked:
https://lists.nongnu.org/archive/html/sks-devel/2013-12/msg00076.html

Seems like keyservers should not be used. Unless that extra DNS for
automated replies gets implemented - joining keyserver infrastructure
forces however is beyond what I wanted to put into this. I guess I will
make the code for downloading the revocation certificates configurable
and use http/curl.

>> 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.
>
> That makes sense.
>
>>> Add a system daemon for parcimonie
>>
>> But parcimonie already has a system daemon?
>
> AFAICT it only has a per-user daemon.

I see.


Reply to: