[pacman-dev] [PATCH] Create pacman keyring directory if missing
Signed-off-by: Ray Kohler <ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..ccc7f92 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -246,6 +246,12 @@ if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then fi GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}" +# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +# Force mode 700 as gpg complains if any group or other access is present +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 700 "${PACMAN_KEYRING_DIR}" + # Parse and execute command command="$1" if [[ -z "${command}" ]]; then -- 1.7.4.1
On Thu, Mar 24, 2011 at 8:05 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
Signed-off-by: Ray Kohler <ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..ccc7f92 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -246,6 +246,12 @@ if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then fi GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}"
+# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +# Force mode 700 as gpg complains if any group or other access is present +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 700 "${PACMAN_KEYRING_DIR}" + # Parse and execute command command="$1" if [[ -z "${command}" ]]; then -- 1.7.4.1
Hi, Ray. I would like to say that the creation of the directory was originally a feature of pacman-key. But Allan suggested to move the responsibility to the makefile of pacman, so the keyring would be created empty by the build system. It is yet a TODO item, indeed. So, it's the distribution duty to package it the way it fits better for them. By the other hand, I was thinking about that while writing this message, and I think that you are right. pacman-key should generate an empty keyring if there is not one. If we leave to a package, it could bet messy if the user tries to reinstall the package or if there is an update for it. It would generate unnecessary .pacnew files for each one in the keyring. pacman-key already has a feature to add and remove keys from keyrings made specifically for that purpose. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Thu, Mar 24, 2011 at 8:00 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Mar 24, 2011 at 8:05 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
Signed-off-by: Ray Kohler <ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..ccc7f92 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -246,6 +246,12 @@ if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then fi GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}"
+# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +# Force mode 700 as gpg complains if any group or other access is present +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 700 "${PACMAN_KEYRING_DIR}"
Why 700? Any reason a normal user should not be able to read this and validate a package on a non-root operation? e.g. pacman -Qlp <package> should run our GPG machinery eventually if a .sig is sitting alongside.
+ # Parse and execute command command="$1" if [[ -z "${command}" ]]; then -- 1.7.4.1
Hi, Ray.
I would like to say that the creation of the directory was originally a feature of pacman-key. But Allan suggested to move the responsibility to the makefile of pacman, so the keyring would be created empty by the build system. It is yet a TODO item, indeed. So, it's the distribution duty to package it the way it fits better for them. We lazily create sync/ directories in pacman; I don't see why pacman-key shouldn't create its directory if necessary either. I'm all for this.
On 25/03/11 11:32, Dan McGee wrote:
On Thu, Mar 24, 2011 at 8:00 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Mar 24, 2011 at 8:05 PM, Ray Kohler<ataraxia937@gmail.com> wrote:
Signed-off-by: Ray Kohler<ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..ccc7f92 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -246,6 +246,12 @@ if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then fi GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}"
+# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +# Force mode 700 as gpg complains if any group or other access is present +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 700 "${PACMAN_KEYRING_DIR}"
Why 700? Any reason a normal user should not be able to read this and validate a package on a non-root operation? e.g. pacman -Qlp<package> should run our GPG machinery eventually if a .sig is sitting alongside.
gpg makes warnings about anything else. These warnings can be suppressed with command-line gpg usage, so I guess they can be suppressed in gpgme. Allan
On Thu, Mar 24, 2011 at 9:49 PM, Allan McRae <allan@archlinux.org> wrote:
On 25/03/11 11:32, Dan McGee wrote:
On Thu, Mar 24, 2011 at 8:00 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Mar 24, 2011 at 8:05 PM, Ray Kohler<ataraxia937@gmail.com> wrote:
Signed-off-by: Ray Kohler<ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..ccc7f92 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -246,6 +246,12 @@ if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then fi GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}"
+# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +# Force mode 700 as gpg complains if any group or other access is present +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 700 "${PACMAN_KEYRING_DIR}"
Why 700? Any reason a normal user should not be able to read this and validate a package on a non-root operation? e.g. pacman -Qlp<package> should run our GPG machinery eventually if a .sig is sitting alongside.
gpg makes warnings about anything else. These warnings can be suppressed with command-line gpg usage, so I guess they can be suppressed in gpgme.
I agree, that would be nicer than locking non-root users out - but I don't know how it's done.
Use mode 755, so non-root users can see inside. Add "--no-permission-warning" to GPG_PACMAN to suppress the noise that otherwise comes of not using mode 700 - this is not private data. GPGme turns out not to issue this warning itself, so no problem there. TODO: should non-root users be allowed to use the read-only operations (--list, --export, --finger)? Signed-off-by: Ray Kohler <ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..89e52fc 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -244,7 +244,12 @@ fi if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then PACMAN_KEYRING_DIR="${GPGDIR}" fi -GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}" +GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR} --no-permission-warning" + +# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 755 "${PACMAN_KEYRING_DIR}" # Parse and execute command command="$1" -- 1.7.4.1
On Sun, Mar 27, 2011 at 11:14 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
Use mode 755, so non-root users can see inside. Add "--no-permission-warning" to GPG_PACMAN to suppress the noise that otherwise comes of not using mode 700 - this is not private data.
GPGme turns out not to issue this warning itself, so no problem there.
TODO: should non-root users be allowed to use the read-only operations (--list, --export, --finger)? I would say yes- is there any reason not to allow them to?
Signed-off-by: Ray Kohler <ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..89e52fc 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -244,7 +244,12 @@ fi if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then PACMAN_KEYRING_DIR="${GPGDIR}" fi -GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}" +GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR} --no-permission-warning" + +# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 755 "${PACMAN_KEYRING_DIR}"
# Parse and execute command command="$1" -- 1.7.4.1
On Sun, Mar 27, 2011 at 10:32 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sun, Mar 27, 2011 at 11:14 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
Use mode 755, so non-root users can see inside. Add "--no-permission-warning" to GPG_PACMAN to suppress the noise that otherwise comes of not using mode 700 - this is not private data.
GPGme turns out not to issue this warning itself, so no problem there.
TODO: should non-root users be allowed to use the read-only operations (--list, --export, --finger)? I would say yes- is there any reason not to allow them to?
I'll do that, then - but in a second patch, not an update to this one.
On Sun, Mar 27, 2011 at 10:43 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
On Sun, Mar 27, 2011 at 10:32 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sun, Mar 27, 2011 at 11:14 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
Use mode 755, so non-root users can see inside. Add "--no-permission-warning" to GPG_PACMAN to suppress the noise that otherwise comes of not using mode 700 - this is not private data.
GPGme turns out not to issue this warning itself, so no problem there.
TODO: should non-root users be allowed to use the read-only operations (--list, --export, --finger)? I would say yes- is there any reason not to allow them to?
I'll do that, then - but in a second patch, not an update to this one.
The apparently read-only operations turn out not to be so. gpg insists on creating a lock file in the homedir, such that even if we grant non-root users read access to the homedir, pubring, and trustdb, these will still fail: $ ./pacman-key -l gpg: failed to create temporary file `/etc/pacman.d/gnupg/.#lk0x911500.asenath.cc.cmu.edu.26039': Permission denied gpg: fatal: can't create lock for `/etc/pacman.d/gnupg/trustdb.gpg' secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 I'm going to bail out on this one.
On 25/03/11 11:00, Denis A. Altoé Falqueto wrote:
On Thu, Mar 24, 2011 at 8:05 PM, Ray Kohler<ataraxia937@gmail.com> wrote:
Signed-off-by: Ray Kohler<ataraxia937@gmail.com> --- scripts/pacman-key.sh.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5746e64..ccc7f92 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -246,6 +246,12 @@ if [[ GPGDIR=$(find_config "GPGDir") == 0 ]]; then fi GPG_PACMAN="gpg --homedir ${PACMAN_KEYRING_DIR}"
+# Try to create $PACMAN_KEYRING_DIR if non-existent +# Check for simple existence rather than for a directory as someone may want +# to use a symlink here +# Force mode 700 as gpg complains if any group or other access is present +[[ -e ${PACMAN_KEYRING_DIR} ]] || mkdir -p -m 700 "${PACMAN_KEYRING_DIR}" + # Parse and execute command command="$1" if [[ -z "${command}" ]]; then -- 1.7.4.1
Hi, Ray.
I would like to say that the creation of the directory was originally a feature of pacman-key. But Allan suggested to move the responsibility to the makefile of pacman, so the keyring would be created empty by the build system. It is yet a TODO item, indeed. So, it's the distribution duty to package it the way it fits better for them.
By the other hand, I was thinking about that while writing this message, and I think that you are right. pacman-key should generate an empty keyring if there is not one. If we leave to a package, it could bet messy if the user tries to reinstall the package or if there is an update for it. It would generate unnecessary .pacnew files for each one in the keyring. pacman-key already has a feature to add and remove keys from keyrings made specifically for that purpose.
I agree. I still think these folder should be created by "make install" but it makes sense for pacman-key to create the folder if it does not exist. My pacman-git PKGBUILD has this in it.... install -dm700 $pkgdir/etc/pacman.d/gnupg touch $pkgdir/etc/pacman.d/gnupg/{sec,pub}ring.gpg chmod 600 $pkgdir/etc/pacman.d/gnupg/{sec,pub}ring.gpg Does not having those keyring files also cause issues here and need to be addressed? Or have I just been over cautious in packaging there? Allan
On Thu, Mar 24, 2011 at 9:36 PM, Allan McRae <allan@archlinux.org> wrote:
I agree. I still think these folder should be created by "make install" but it makes sense for pacman-key to create the folder if it does not exist.
My pacman-git PKGBUILD has this in it....
install -dm700 $pkgdir/etc/pacman.d/gnupg touch $pkgdir/etc/pacman.d/gnupg/{sec,pub}ring.gpg chmod 600 $pkgdir/etc/pacman.d/gnupg/{sec,pub}ring.gpg
Does not having those keyring files also cause issues here and need to be addressed? Or have I just been over cautious in packaging there?
gpg will create the keyring files themselves if they don't exist. It will only complain about the missing directory, and never try to fix it, so it needs some hand-holding there.
participants (4)
-
Allan McRae
-
Dan McGee
-
Denis A. Altoé Falqueto
-
Ray Kohler