| Message ID | 20220101194934.8229-1-jeremy@merelinux.org |
|---|---|
| Headers | show |
| Series | Initial support for asignify signatures | expand |
On Sat, Jan 1, 2022 at 2:49 PM Jeremy Huntwork <jeremy@merelinux.org> 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. :) Thanks again, JH
On 13/1/22 23:24, Jeremy Huntwork wrote: > On Sat, Jan 1, 2022 at 2:49 PM Jeremy Huntwork <jeremy@merelinux.org> 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 <allan@archlinux.org> wrote: > 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/doc/libsodium_users JH
On Thu, Jan 13, 2022 at 10:39 AM Jeremy Huntwork <jeremy@merelinux.org> wrote:
> used already: https://libsodium.gitbook.io/doc/libsodium_usershttps://libsodium.gitbook.io/doc/libsodium_usersMet
Meh, bad paste sorry. It's probably obvious but the correct link is
https://libsodium.gitbook.io/doc/libsodium_users