[pacman-dev] [PATCH] pacman-key: rework importing distro/repo provided keyrings

[Denis A. Altoé Falqueto]

On Wed, Aug 17, 2011 at 9:49 PM, Allan McRae <allan at archlinux.org> wrote:
> On 18/08/11 08:48, Dan McGee wrote:

Hi, guys. I would like to add some notes on what Allan replied.

>> Optionally,<comma>
>> `foo-revoked.gpg` (forgot the extension here too). Or did I
>> misunderstand and this is a text file with IDs rather than an actual
>> keyring file with binary data? This might require some thought, it
>> looks like I did misunderstand.
>> "IDs" is the capitalization used in the gpg manpage.
>
> Yes - the foo-revoked file is a list of key IDs rather than a keyring. I
> just went with extending what was already implemented previously so I guess
> this is how it is done in apt-key.  When you say "requires more thought" do
> you mean in the description or implementation?

I don't remember exactly if it was in apt-get, but even if it isn't,
it's not that useful to have a real keyring for the revoked keys. What
is really needed is a way to identify a key to be removed. If we had a
real keyring we would just add another command to the pipe to get the
key IDs without any real gain. So, using the IDs from the start is all
that we need.

>>>        # List of keys that must be kept installed, even if in the list of
>>> keys to be removed
>>>        local HOLD_KEYS="$(get_from "$CONFIG" "HoldKeys")"
>>
>> This is something I hadn't noticed before. How exactly does this hold
>> keys stuff work? man pacman-key, /hold shows me nothing.
>
> Looks like this was never documented anywhere...  My understanding is that
> you can provide a list of keys to never be removed from the keyring in using
> "HoldKey = " in pacman.conf.
>
> Thinking about this, I'm not sure that is really an option for pacman.conf,
> but it does seem like something that is a useful feature. Suggestions for
> how it should be adjusted?

I think I forgot to write the corresponding documentation when I sent
the patch [1]. Sorry for that...

To summarize, when I made the patch, I worked with 3 sets of keys:
current, deprecated and removed. Current and deprecated would still be
added by the reload operation (now renamed to populate). Only keys in
the removed set would really be dropped from the keyring. In that
context, I thought of adding Holdkey as a way to allow the end user to
avoid having to re-add a needed key if it was marked to be removed.

My initial use case was based on the my personal premise that a
ex-developer's key would be removed by the time of his departure. In
that situation, maybe his key would still be useful for other personal
repositories he could keep maintaining elsewhere. But if a developer's
key is kept even after he leaves, the premise is not true anymore and
HoldKey would lose a potential use case. But maybe it is a matter of
distribution policy, so it could still be useful to have such an
option.

[1] http://archlinux.2023198.n4.nabble.com/Appendix-to-signature-patchset-td2957161.html#a3051509

-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
Linux user #524555
-------------------------------------------