[pacman-dev] Appendix to signature patchset
Guys, This is a last patch for that series. It is a new patch, as Allan asked, so you can apply it in an already patched branch. The description on the patch itself is self explanatory. This is just to justify the new patch without poluting its description. Any sugestions or criticisms are always welcome. -- Denis Falqueto
The --reload command was refactored to allow a more flexible management.
There are two sets of keys that will be added, one that will be
removed and one that will be kept.
The set of keys to be kept are configured in pacman.conf, with the
option HoldKeys, with the same meaning of HoldPkgs. It can be repeated
and several values can be put in the same entry.
The new behavior allows a key to be marked for removal, but the user
can decide if that key must be kept. For example, if a developer has
a public repository, signed with his own key, that key must be added
to the HoldKeys option. If the key is marked for removal from pacman's
keyring, it will not be removed for the users that have configured
HoldKeys correctly.
There are other minor fixes, mainly in the handling of --add command
when there is no aditional parameter. In that case, pacman-key will
behave just like gpg, adding the contents of stdin into pacman's keyring.
Signed-off-by: Denis A. Altoé Falqueto
On 06/10/10 12:26, Denis A. Altoé Falqueto wrote:
The --reload command was refactored to allow a more flexible management. There are two sets of keys that will be added, one that will be removed and one that will be kept.
<snip>
Signed-off-by: Denis A. Altoé Falqueto
--- scripts/pacman-key.sh.in | 152 +++++++++++++++++++++++++++++++++------------- 1 files changed, 110 insertions(+), 42 deletions(-)
Looks file to me overall. A couple of comments/queries below: <snip>
+find_config() { + # Prints on stdin the values of all the options from the configuration file that + # are associated with the first parameter of this function. + # The option names are stripped + if (( $# == 0 )); then + error "find_config: missing parameter" + exit 1 + fi
Given this is only being called from within the script, I really do not think we need the error check there.
+ grep -e "^[[:blank:]]*$1[[:blank:]]*=.*" "$CONFIG" | cut -d= -f 2- +} +
<snip>
+ + # Read the key ids to an array. The conversion from whatever is inside the file + # to key ids is important, because key ids are the only guarantee of identification + # for the keys. + local -A removed_ids + if [[ -r "${REMOVED_KEYS}" ]]; then + while read key; do + local key_values name + key_values=$(${GPG_PACMAN} --quiet --with-colons --list-key "${key}" | grep ^pub | cut -d: -f5,10 --output-delimiter=' ') + if [[ -z $key_values ]]; then + # The key is not in pacman's keyring, so search it on the added and deprecated keys
This I do not understand. Surely if a key is in the remove list then it is not in the added or deprecated list. I'd assume that if a key is to be removed and is not in the keyring already, then we have to do nothing. Either that or if it could be added via the added and deprecated lists, deal with those first and just remove them all at the end. I know it is a waste to add the key only to remove it later in that weird situation, but it would simplify this section of the code a lot. Allan
On Thu, Oct 7, 2010 at 1:34 AM, Allan McRae
+ + # Read the key ids to an array. The conversion from whatever is inside the file + # to key ids is important, because key ids are the only guarantee of identification + # for the keys. + local -A removed_ids + if [[ -r "${REMOVED_KEYS}" ]]; then + while read key; do + local key_values name + key_values=$(${GPG_PACMAN} --quiet --with-colons --list-key "${key}" | grep ^pub | cut -d: -f5,10 --output-delimiter=' ') + if [[ -z $key_values ]]; then + # The key is not in pacman's keyring, so search it on the added and deprecated keys
This I do not understand. Surely if a key is in the remove list then it is not in the added or deprecated list. I'd assume that if a key is to be removed and is not in the keyring already, then we have to do nothing.
Either that or if it could be added via the added and deprecated lists, deal with those first and just remove them all at the end. I know it is a waste to add the key only to remove it later in that weird situation, but it would simplify this section of the code a lot.
Yes, you're right. I was overcomplicating because on my tests I created a too convoluted situation that would not really happen in real life. Do you want me to resend the patch or will you adapt it before including in your repository? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 08/10/10 00:46, Denis A. Altoé Falqueto wrote:
On Thu, Oct 7, 2010 at 1:34 AM, Allan McRae
wrote: + + # Read the key ids to an array. The conversion from whatever is inside the file + # to key ids is important, because key ids are the only guarantee of identification + # for the keys. + local -A removed_ids + if [[ -r "${REMOVED_KEYS}" ]]; then + while read key; do + local key_values name + key_values=$(${GPG_PACMAN} --quiet --with-colons --list-key "${key}" | grep ^pub | cut -d: -f5,10 --output-delimiter=' ') + if [[ -z $key_values ]]; then + # The key is not in pacman's keyring, so search it on the added and deprecated keys
This I do not understand. Surely if a key is in the remove list then it is not in the added or deprecated list. I'd assume that if a key is to be removed and is not in the keyring already, then we have to do nothing.
Either that or if it could be added via the added and deprecated lists, deal with those first and just remove them all at the end. I know it is a waste to add the key only to remove it later in that weird situation, but it would simplify this section of the code a lot.
Yes, you're right. I was overcomplicating because on my tests I created a too convoluted situation that would not really happen in real life.
Do you want me to resend the patch or will you adapt it before including in your repository?
That adjustment is big enough that resending the patch would be helpful. Otherwise it might take some time for me to get it adjusted... Allan
The --reload command was refactored to allow a more flexible management.
There are two sets of keys that will be added, one that will be
removed and one that will be kept.
The set of keys to be kept are configured in pacman.conf, with the
option HoldKeys, with the same meaning of HoldPkgs. It can be repeated
and several values can be put in the same entry.
The new behavior allows a key to be marked for removal, but the user
can decide if that key must be kept. For example, if a developer has
a public repository, signed with his own key, that key must be added
to the HoldKeys option. If the key is marked for removal from pacman's
keyring, it will not be removed for the users that have configured
HoldKeys correctly.
There are other minor fixes, mainly in the handling of --add command
when there is no aditional parameter. In that case, pacman-key will
behave just like gpg, adding the contents of stdin into pacman's keyring.
Signed-off-by: Denis A. Altoé Falqueto
On Thu, Oct 7, 2010 at 9:03 PM, Denis A. Altoé Falqueto
.....
Sorry, ignore this patch, please. I forgot the --homedir option. Without it, there'll be a nasty message about missing /root/.gpg, bla bla bla... I'll send the right one very soon. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
The --reload command was refactored to allow a more flexible management.
There are two sets of keys that will be added, one that will be
removed and one that will be kept.
The set of keys to be kept are configured in pacman.conf, with the
option HoldKeys, with the same meaning of HoldPkgs. It can be repeated
and several values can be put in the same entry.
The new behavior allows a key to be marked for removal, but the user
can decide if that key must be kept. For example, if a developer has
a public repository, signed with his own key, that key must be added
to the HoldKeys option. If the key is marked for removal from pacman's
keyring, it will not be removed for the users that have configured
HoldKeys correctly.
There are other minor fixes, mainly in the handling of --add command
when there is no aditional parameter. In that case, pacman-key will
behave just like gpg, adding the contents of stdin into pacman's keyring.
Signed-off-by: Denis A. Altoé Falqueto
On 08/10/10 10:13, Denis A. Altoé Falqueto wrote:
The --reload command was refactored to allow a more flexible management. There are two sets of keys that will be added, one that will be removed and one that will be kept.
The set of keys to be kept are configured in pacman.conf, with the option HoldKeys, with the same meaning of HoldPkgs. It can be repeated and several values can be put in the same entry.
The new behavior allows a key to be marked for removal, but the user can decide if that key must be kept. For example, if a developer has a public repository, signed with his own key, that key must be added to the HoldKeys option. If the key is marked for removal from pacman's keyring, it will not be removed for the users that have configured HoldKeys correctly.
There are other minor fixes, mainly in the handling of --add command when there is no aditional parameter. In that case, pacman-key will behave just like gpg, adding the contents of stdin into pacman's keyring.
Signed-off-by: Denis A. Altoé Falqueto
--- scripts/pacman-key.sh.in | 141 ++++++++++++++++++++++++++++++++-------------- 1 files changed, 99 insertions(+), 42 deletions(-)
Finally got to the re-review of this... it looks like all my original comments were addressed. Pulled onto my newly rebased gpg branch. Allan
On 06/10/10 12:26, Denis A. Altoé Falqueto wrote:
Guys,
This is a last patch for that series. It is a new patch, as Allan asked, so you can apply it in an already patched branch.
The description on the patch itself is self explanatory. This is just to justify the new patch without poluting its description.
Any sugestions or criticisms are always welcome.
Thanks, I will look at this in the coming days and rebase it into the previous keyring patch as necessary. I am also part way through reviewing the next patch in the series so expect a reply to that in the next few days. Cheers, Allan
participants (2)
-
Allan McRae
-
Denis A. Altoé Falqueto