[PATCH 0/4] Initial support for asignify signatures

[Allan McRae]

On 13/1/22 23:24, Jeremy Huntwork wrote:
> On Sat, Jan 1, 2022 at 2:49 PM Jeremy Huntwork <jeremy at 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