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: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.

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.

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

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.