[PATCH 0/4] Initial support for asignify signatures

Jeremy Huntwork jeremy at merelinux.org
Thu Jan 13 15:39:18 UTC 2022


On Thu, Jan 13, 2022 at 9:32 AM Allan McRae <allan at 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


More information about the pacman-dev mailing list