[PATCH 0/4] Initial support for asignify signatures
libasignify provides a simple API for checking ed25519 signatures of blake2 file digests. See: https://github.com/vstakhov/asignify These changes add support into libalpm, a new configuration option for the location of trusted public keys that libasignify uses, and modify the build to support only one signature method, gpgme or asignify. A future patch will be needed to add appropriate asignify signing commands to makepkg. Jeremy Huntwork (4): libalpm: Add support for asignify signatures Add a configuration option for asignify's key dir Add documentation for the AsignifyDir option Update meson for asignify doc/pacman.conf.5.asciidoc | 8 +++++ etc/pacman.conf.in | 1 + lib/libalpm/alpm.c | 2 +- lib/libalpm/alpm.h | 19 +++++++++++ lib/libalpm/be_package.c | 22 ++++++++++--- lib/libalpm/be_sync.c | 2 +- lib/libalpm/error.c | 8 ++--- lib/libalpm/handle.c | 23 ++++++++++++-- lib/libalpm/handle.h | 1 + lib/libalpm/signing.c | 65 ++++++++++++++++++++++++++++++++++++++ lib/libalpm/signing.h | 1 + meson.build | 33 +++++++++++++------ meson_options.txt | 4 +-- src/pacman/conf.c | 16 ++++++++++ src/pacman/conf.h | 2 ++ src/pacman/pacman.c | 40 ++++++++++++++++++----- test/pacman/meson.build | 2 +- 17 files changed, 216 insertions(+), 33 deletions(-) -- 2.34.1
Provide an alternative way to validate package and repository signatures
using libasignify. See: https://github.com/vstakhov/asignify
Signed-off-by: Jeremy Huntwork
Following the pattern used by gpgdir, set asignifydir to the location
where libasignify will look for and load public keys.
Since the intent is to only support one signature method at a time, wrap
the `--gpgdir` and `--asignifydir` flags in ifdef blocks.
Signed-off-by: Jeremy Huntwork
Signed-off-by: Jeremy Huntwork
Change the meson configuration so that only one signature method, either
gpgme or asignify, is supported at build time.
Signed-off-by: Jeremy Huntwork
On Sat, Jan 1, 2022 at 2:49 PM Jeremy Huntwork
libasignify provides a simple API for checking ed25519 signatures of blake2 file digests. See: https://github.com/vstakhov/asignify
These changes add support into libalpm, a new configuration option for the location of trusted public keys that libasignify uses, and modify the build to support only one signature method, gpgme or asignify.
A future patch will be needed to add appropriate asignify signing commands to makepkg.
Jeremy Huntwork (4): libalpm: Add support for asignify signatures Add a configuration option for asignify's key dir Add documentation for the AsignifyDir option Update meson for asignify
doc/pacman.conf.5.asciidoc | 8 +++++ etc/pacman.conf.in | 1 + lib/libalpm/alpm.c | 2 +- lib/libalpm/alpm.h | 19 +++++++++++ lib/libalpm/be_package.c | 22 ++++++++++--- lib/libalpm/be_sync.c | 2 +- lib/libalpm/error.c | 8 ++--- lib/libalpm/handle.c | 23 ++++++++++++-- lib/libalpm/handle.h | 1 + lib/libalpm/signing.c | 65 ++++++++++++++++++++++++++++++++++++++ lib/libalpm/signing.h | 1 + meson.build | 33 +++++++++++++------ meson_options.txt | 4 +-- src/pacman/conf.c | 16 ++++++++++ src/pacman/conf.h | 2 ++ src/pacman/pacman.c | 40 ++++++++++++++++++----- test/pacman/meson.build | 2 +- 17 files changed, 216 insertions(+), 33 deletions(-)
Hi, any feedback on this? I'm at the point in my own project where I need to decide how I'm moving forward, so it would be nice to have a feel for which way the wind is blowing. :) Thanks again, JH
On 13/1/22 23:24, Jeremy Huntwork wrote:
On Sat, Jan 1, 2022 at 2:49 PM Jeremy Huntwork
wrote: libasignify provides a simple API for checking ed25519 signatures of blake2 file digests. See: https://github.com/vstakhov/asignify
These changes add support into libalpm, a new configuration option for the location of trusted public keys that libasignify uses, and modify the build to support only one signature method, gpgme or asignify.
A future patch will be needed to add appropriate asignify signing commands to makepkg.
Jeremy Huntwork (4): libalpm: Add support for asignify signatures Add a configuration option for asignify's key dir Add documentation for the AsignifyDir option Update meson for asignify
doc/pacman.conf.5.asciidoc | 8 +++++ etc/pacman.conf.in | 1 + lib/libalpm/alpm.c | 2 +- lib/libalpm/alpm.h | 19 +++++++++++ lib/libalpm/be_package.c | 22 ++++++++++--- lib/libalpm/be_sync.c | 2 +- lib/libalpm/error.c | 8 ++--- lib/libalpm/handle.c | 23 ++++++++++++-- lib/libalpm/handle.h | 1 + lib/libalpm/signing.c | 65 ++++++++++++++++++++++++++++++++++++++ lib/libalpm/signing.h | 1 + meson.build | 33 +++++++++++++------ meson_options.txt | 4 +-- src/pacman/conf.c | 16 ++++++++++ src/pacman/conf.h | 2 ++ src/pacman/pacman.c | 40 ++++++++++++++++++----- test/pacman/meson.build | 2 +- 17 files changed, 216 insertions(+), 33 deletions(-)
Hi, any feedback on this? I'm at the point in my own project where I need to decide how I'm moving forward, so it would be nice to have a feel for which way the wind is blowing. :)
The wind is not gusting too hard in any direction... I like the approach and the patches look relatively fine, but it seems the number of signify type approaches in the world is increasing. So decisions need to be made looking forward and trying to guess what the landscape will look like over the next few years. My crystal ball is a bit foggy, and I don't have time at the moment to spend clarifying it. If this was using a library *fully* implementing the OpenBSD signify, I would likely accept immediately. That is a format that will likely exist for a while. As far as I can tell, asignify is not used by any other project. It seems to have been dormant from 2015 until 2021, where some development restarted. The positive is that it will read signatures from signify. And that is where I am at considering these patches. I'm not sure what would convince me either way... Allan
On Thu, Jan 13, 2022 at 9:32 AM Allan McRae
The wind is not gusting too hard in any direction... I like the approach and the patches look relatively fine, but it seems the number of signify type approaches in the world is increasing. So decisions need to be made looking forward and trying to guess what the landscape will look like over the next few years. My crystal ball is a bit foggy, and I don't have time at the moment to spend clarifying it.
If this was using a library *fully* implementing the OpenBSD signify, I would likely accept immediately. That is a format that will likely exist for a while.
As far as I can tell, asignify is not used by any other project. It seems to have been dormant from 2015 until 2021, where some development restarted. The positive is that it will read signatures from signify.
And that is where I am at considering these patches. I'm not sure what would convince me either way...
Awesome, thank you, that helps tremendously. I completely understand the reservation about asignify. It helps when there is already wider adoption. As stated elsewhere, I chose it mainly for simplicity - initially the thought of adding in patches to pacman was a bit daunting. I agree that signify or possibly minisign/libsodium would feel more comfortable on that score. Now that I have a better feel for the code base, perhaps I can look at one of those instead. Between those two, would you have a preference? asignify requires libbsd, so I'm inclined to start with minisign, especially as libsodium seems to be broadly used already: https://libsodium.gitbook.io/doc/libsodium_usershttps://libsodium.gitbook.io... JH
On Thu, Jan 13, 2022 at 10:39 AM Jeremy Huntwork
used already: https://libsodium.gitbook.io/doc/libsodium_usershttps://libsodium.gitbook.io...
Meh, bad paste sorry. It's probably obvious but the correct link is https://libsodium.gitbook.io/doc/libsodium_users
participants (2)
-
Allan McRae
-
Jeremy Huntwork