vstakhov/asignify

Yet another signify tool

asignify's Issues

The file path is encoded into the digest (and, is the name really needed?)

... and asignify check requires to be given the same path when checking a digest, or else it will not find the file in the digest. Ugh, this is not very user friendly.

I mean, relative directories might be useful if we're signing a whole directory tree (and there are multiple files with the same name in different subdirs), but then the code should be way smarter (as in, normalize all paths, find the "root point", only match the path components past the root point when checking, etc.), but I don't see any intent to support directories in the code, just "file1 file2" so using asignify like this would be difficult (one would need to use other tools to generate the file list of the whole tree.)

Anyways, I think it should be possible to have a 1-file signature without any filename inside, just the hash (as in, "BLAKE2 = abcdef..."), and asignify check should try the nameless hash for the first file given.

The library does not seem to allow making multiple signatures with one password entry?

I'd like to sign a package repository (like, 2174 files now :P), adding a .sig file next to each package, but keep the private key password protected while i'm not doing that.

The library API seems to be designed to not allow a reset of the file list for the signing context? (IOW, restart of the process from the point the private key was loaded.) It's not hard to add, but I'm just so so so confused as to how you're using this that you didn't think of adding that, lol.

(Be prepared for a pull request once I'm done fixing this, this is just advance info :P)

check+echo mode

This is something I've been tossing back and forth that I think I'd like to implement before trying to import asignify into FreeBSD base.

The basic idea is pretty simple: given an existing pubkey and sigfile, output the contents if verification passes. Use case, for example:

# $pubkey already exists
fetch https://kevans.dev/script.sh.sig
fetch -o - https://kevans.dev/script.sh | asignify check -x $pubkey script.sh.sig - > script.sh
[ ! -s "script.sh" ] && exit 1

Though, I picture a more realistic use-case to be:

# $pubkey already exists
fetch https://kevans.dev/script.sh.sig
fetch -o - https://kevans.dev/script.sh | asignify check -x $pubkey script.sh.sig - | sh

This would be a slightly better version of existing curl|sh constructs, since we'll execute the script only if verification succeeds against our known-good key.

asignify sign and none exists files

If you try to sign files which of them exist and one of them don't you can see a wrong logic.

1. Scenario #1 (first file exist, second don't)

# ./src/asignify sign -n -d blake2 -n src/key.sec ./src/asignify.sig ./src/asignify ./src/asignify-nosuchfile
Password:
added BLAKE2 digest of ./src/asignify
cannot sign file ./src/asignify1: file IO error
# cat ./src/asignify.sig 
asignify-sig:1:qeLlRHNPnb8=:DAwkURwVmTpVl98QCTOUlS1jaEQQiYfFCILN9TjUtAHVHYFCyPnFRiThEGGFNrwLW83S/Xl0vujvPIzAQnbzCQ==
BLAKE2 (./src/asignify) = 8da76a9ece762e7d3bd9fdbc2562905c64b16a386372276e0f6c712adb8a53d49f3e6c26e2e48592eb245ff28d60e312b8c1c0bb2735a754764abbeadaeece5b

Scenario #2 (first file don't exist, second exist)

# ./src/asignify sign -n -d blake2 -n src/key.sec ./src/asignify.sig ./src/asignify-nosuchfile ./src/asignify
Password:
cannot sign file ./src/asignify1: file IO error
# cat ./src/asignify.sig
cat: ./src/asignify.sig: No such file or directory

I think you need skip none exists files with warning and continue to process existing.

Status

Hi,
What is the current project status? Is it unmaintained or still alive?

gcc 11.x - error: size of array element is not a multiple of its alignment

With current gcc 11.x you get an error when compiling asignify.
I found more details in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1937076

A possible fix could look like according to that bug report:

diff --git a/libasignify/blake2.h b/libasignify/blake2.h
index 5d0d40c..f9967d0 100644
--- a/libasignify/blake2.h
+++ b/libasignify/blake2.h
@@ -56,7 +56,7 @@ extern "C" {
uint8_t personal[BLAKE2B_PERSONALBYTES]; // 64
} blake2b_param;

• BLAKE_ALIGN( 64 ) typedef struct __blake2b_state

• typedef struct BLAKE_ALIGN( 64 ) __blake2b_state
  {
  uint64_t h[8];
  uint64_t t[2];

read_password() example in README.md

the code should check the password fits in the buffer before calling memcpy() (even though in this particular example the check isn't necessary).

// sorry to submit this as an issue but i'm too sleepy for a pull request:)

Tests

I've got a branch queued up that basically rototills the libasignify API to take FILE * everywhere rather than opening files itself (mostly) -- mostly to support pkg or other applications that may want to just encrypt/decrypt/sign in memory (the new variants still take filenames). Before landing it, though, I'd like to at least put some frontend tests into place so we can have some confidence that asignify works like we're expecting before and after.

I've got some WIP[0] for this that currently just consists of some rogue shell scripts that speak TAP, but I'm not convinced that that's necessarily the best approach.

[0] master...kevans91:test

Was there ever an asignify 1.1 release?

Hello,

A few years ago I packaged asignify for the GNU Guix distro:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=de15ff1a6c319a46046093d26baa6117c6a22e73

As you can see, I used a version of "1.1", along with some extra info we use when packaging from Git sources.

I started updating this package recently and noticed that there is no 1.1 release tag for asignify.

Did I make a mistake? Or was 1.1 recalled?