Heya, it seems the windows build isn't v0.3, as it lacks -v and -P, same goes for the bundled copy with dnscrypt as it's the same file.

Installed minisign on OS X 10.8.5 via brew install.

When verifying, using the default public key file or specifying the public key directly via -P work fine, but having trouble with the -p option (read public key from file):

% minisign -G
Please enter a password to protect the secret key.

Password: 
Password (one more time): 
Deriving a key from the password in order to encrypt the secret key... done

The secret key was saved as minisign.key - Keep it secret!
The public key was saved as minisign.pub - That one can be public.

Files signed using this key pair can be verified with the following command:

minisign -Vm <file> -P RWTi4OFrWLw+qAf5Jb8D+aTpAX3NG4DCaFP6kyMsuFOGZ1Sn/vgJWhkR

% ls
minisign.key    minisign.pub    testfile
% minisign -Sm testfile -s minisign.key # name private key file explicitly
Password: 
Deriving a key from the password and decrypting the secret key... done

% ls
minisign.key    minisign.pub    testfile    testfile.minisig
% minisign -Vm testfile -x testfile.minisig # use default public key file in current directory
Signature and comment signature verified
Trusted comment: timestamp:1445550164   file:testfile
% minisign -Vm testfile x testfile.minisig -P RWSZ...2paS # specify public key directly
Signature and comment signature verified
Trusted comment: timestamp:1445550164   file:testfile
% minisign -Vm tesfdile -x testfile.minisig -p minisign.pub # name public key file explicitly
Usage:
minisign -G [-p pubkey] [-s seckey]
minisign -S [-x sigfile] [-s seckey] [-c untrusted_comment] [-t trusted_comment] -m file
minisign -V [-x sigfile] [-p pubkeyfile | -P pubkey] [-q] -m file
...

Can't see what, if anything, I'm doing wrong when using the -p option, but I also find it hard to believe that in code available though Homebrew, something so basic could be broken.

Currently the binary will create the minisign.key, minisign.pub and .minisig file in a customised format, generally containing prefixed byte data, in my situation I need the raw values without the other information.

So my suggestion is It might be a good idea to provide a option which allows you produce the pure key/sign values for use with testing other implementations of ed25519 which do not rely on the hash identify or the 8bytes etc.

Thanks,

I found that in issue #40 have request to using minisign as library and I already have experience with meson build project as dependency.

I prepare meson project wrapper and someone may reuse minisign as subproject in future in their application.

You may meet with my change in repositiry https://github.com/vit1251/minisign

How to using meson project as subproject you may see in https://mesonbuild.com/Subprojects.html

Maybe ask if user wants to overwrite?

I'm trying to enhance my minisign-verify workflow by checking the clipboard contents first. So my question is, if the public keys (a) are always 56 characters long, (b) only have "+" and "/" as special characters, and (c) are otherwise made up of A–Z, a–z, and 0-9.

The function I'm currently thinking about for checking the public key is like this:

pkch () {
    case $1 in
        ( *[!0-9A-Za-z+/]* | "" ) echo "false" ;;
        ( * )
            case ${#1} in
                ( 56 ) echo "true" ;;
                ( * ) echo "false" ;;
            esac
    esac
}

EDIT: additional question… public keys always seem to begin with "RW", correct? The function would then be:

pkch () {
    case $1 in
        [!RW]* ) echo "false" ;;
        * )
        case $1 in
            ( *[!0-9A-Za-z+/]* | "" ) echo "false" ;;
            ( * )
                case ${#1} in
                    ( 56 ) echo "true" ;;
                    ( * ) echo "false" ;;
                esac
        esac
    esac
}

Since people are likely to already be managing their ssh-ed25519 keys, and many will be also publishing them to GitHub as well, it would be a really nice feature to be able to use these for signatures. Perhaps also include a feature to convert the ssh pubkey format to the signify pubkey format.

This follows the same concept as @FiloSottile is using for his age encryption project.

Minisign gives me an error when I try to use it to verify a signature made by Signify. From the docs it seems like this is intended to work.

$ echo VGhpcyBpcyBhIHRlc3QgbWVzc2FnZS4K | base64 --decode > message.txt
$ signify -G -p sign.pub -s sign.sec
passphrase: (z)
confirm passphrase: (z)
$ cat sign.sec
untrusted comment: signify secret key
RWRCSwAAACrVwvFk3aEyZFmPQ3kkX8eVAXYt/DvCvS3JD4o2QgWw5dPT1GwM0/u9lgqB03XQqr5yJJx9f49kmX5vd6NBBHa0rk4e9XC8mVs6Q1jWMCmO6aQTjcLOHFhLr9Vxc+W+NSw=
$ signify -S -s sign.sec -m message.txt
passphrase: (z)
$ cat message.txt.sig
untrusted comment: verify with sign.pub
RWTJD4o2QgWw5Yl4xS5JBgxC4Zv+KnDXYfDJzpE6LU/FZbs5vHq2kVJ5E7ruNvUUL+sg1/OSOvnI6N6A57wpc2VrWwujA/m8mwU=
$ ls
message.txt     message.txt.sig sign.pub        sign.sec
$ signify -V -p sign.pub -m message.txt -x message.txt.sig
Signature Verified
$ minisign -V -p sign.pub -m message.txt -x message.txt.sig
message.txt.sig: Undefined error: 0
$ minisign -v
minisign 0.8

The other way around works okay. Signify can verify minisign signatures:

$ rm sign.pub sign.sec
$ minisign -G -p sign.pub -s sign.sec
Please enter a password to protect the secret key.

Password: (z)
Password (one more time):
Deriving a key from the password in order to encrypt the secret key... done

The secret key was saved as sign.sec - Keep it secret!
The public key was saved as sign.pub - That one can be public.

Files signed using this key pair can be verified with the following command:

minisign -Vm <file> -P RWSaFhePk+tC9vTTi+yeIO4Wl6ncKXi9+ic+Rj0nohuwNC/ZWZLgBoEx
$ cat sign.sec
untrusted comment: minisign encrypted secret key
RWRTY0Iy8Ih0p+rQl2n6xucscPJOdSK48PM+Un6uFrhB74CZR/oAAAACAAAAAAAAAEAAAAAAXEf+5XzHb5GZ0vHG9ToGyICcgqEyB6kj1FAX0o/rO5o6bjIPvf3dJYo9qbOUYhWCv+56u9rnEywSGLzL9+XFmp3B2wwh14cw2+VsVe6saQG/fjrI2/C3vjUbpX1pKzGhGO391w6IawQ=
$ minisign -S -s sign.sec -m message.txt
Password: (z)
Deriving a key from the password and decrypting the secret key... done
$ cat message.txt.minisig
untrusted comment: signature from minisign secret key
RWSaFhePk+tC9snG7mzd/58ED3RdUFmO3KkyR5K8Vx/4WJCkRqHKBtUAVe4zSkoG2TgDGAImnjKBmHChbbjAxoD+TaY81Owx6AE=
trusted comment: timestamp:1563858228	file:message.txt
D1HGUOIL0Qc9OqibpK7QwMO3crzhoUdaur25n1eyMBL2q4r0loThMZycevcN1bMOg61h6cA5+PuBY8kE6MxFAw==
$ minisign -V -p sign.pub -m message.txt -x message.txt.minisig
Signature and comment signature verified
Trusted comment: timestamp:1563858228	file:message.txt
$ signify -V -p sign.pub -m message.txt -x message.txt.minisig
Signature Verified

Just in case this is somehow system-specific, I'm on MacOS with minisign and signify installed from Homebrew.

$ brew info signify-osx
signify-osx: stable 1.4 (bottled), HEAD
Cryptographically sign and verify files
https://man.openbsd.org/signify.1
/usr/local/Cellar/signify-osx/1.4 (6 files, 174.8KB) *
  Poured from bottle on 2019-07-22 at 14:46:59
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/signify-osx.rb
==> Options
--HEAD
	Install HEAD version
==> Analytics
install: 28 (30 days), 59 (90 days), 221 (365 days)
install_on_request: 28 (30 days), 58 (90 days), 208 (365 days)
build_error: 0 (30 days)
$ brew info minisign
minisign: stable 0.8 (bottled)
Sign files & verify signatures. Works with signify in OpenBSD
https://jedisct1.github.io/minisign/
/usr/local/Cellar/minisign/0.8 (6 files, 38.1KB) *
  Poured from bottle on 2019-07-22 at 13:40:52
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/minisign.rb
==> Dependencies
Build: cmake ✔
Required: libsodium ✔
==> Analytics
install: 85 (30 days), 172 (90 days), 644 (365 days)
install_on_request: 63 (30 days), 116 (90 days), 420 (365 days)
build_error: 0 (30 days)

When you pas the wrong public key (and e.g. accidentally use the signature) you get a base64 error.

# minisign -Vm minisign -P fsadf
base64 conversion failed

I think this error message could be improved as the user does not know what failed to be converted and generally you do not really know what you did wrong here.

Am I too impatient or have the win32 binaries been forgotten? :)

You should consider signing git commits & releases.

• onionshare#221 (comment)
• It is also displayed on GitHub: https://github.com/blog/2144-gpg-signature-verification
• Here is GitHub's help for this: https://help.github.com/articles/generating-a-gpg-key/
• And here is how you can sign releases: https://wiki.debian.org/Creating%20signed%20GitHub%20releases

It would be nice, if there is a precompiled Windows release (like in the dnscrypt-proxy 1.5).

So:

• a precompiled minisign.exe in the release package
• a seperate download/project site

$ ./minisign -G
Please enter a password to protect the secret key.

Password:
Password (one more time):
Deriving a key from the password in order to encrypt the secret key... Aborted (core dumped)

It's this part of generate():

    if (crypto_pwhash_scryptsalsa208sha256
        (stream, sizeof seckey_struct->keynum_sk, pwd, strlen(pwd),
         seckey_struct->kdf_salt,
         le64_load(seckey_struct->kdf_opslimit_le),
         le64_load(seckey_struct->kdf_memlimit_le)) != 0) {
        abort();
    }

Any guidance on what could be going on here?
I'm using libsodium-1.0.18 built without configure parameters on ubuntu 18.04.3 LTS (gcc-7.4.0)

I was doing some testing and had created a zero byte file foo.txt. Trying to sign this (using various permutations) was failing for me with Undefined error: 0. I determined that this happens if the file you are trying to sign is empty. If you put anything in the file it signs normally.

While it may not make sense normally to sign a zero-byte file it should handle this more gracefully and with a meaningful error message.

/tmp/test$ ls -la
total 0
drwxr-xr-x  3 glenn 102 Dec 29 23:12 .
drwxrwxrwt 18 root  612 Dec 29 23:04 ..
-rw-r--r--  1 glenn   0 Dec 29 23:12 foo.txt

/tmp/test$ minisign -Sm foo.txt -s ~/.minisign/minisign.key
Password:
Deriving a key from the password and decrypting the secret key... done

foo.txt: Undefined error: 0

I guess Minisign was not design for Microsoft Windows normal users, like me, since is using command line to be able to use it.
At least for dumb Microsoft Windows users like me (and OSX users), it would be nice for Minisign to have a good GUI interface.
Bring it to the general public people, so simple that even your grandmother could use it, but also with the advanced options that more advanced users may want.

It should allow users to do all the operations that are possible on the GUI interface.
Also allow the "import" (other people public keys) and "export" (user own public key) features, into the same folder.

It should be easy for normal users to just drop file(s) / folder(s) and select to either sign everything with user chosen public key/ verify everything displaying the different files per on the "local database" public key, and maybe also displaying the sign files for whose keys are currently unknown. Also display anything else like version used (Ed25519/Blake2b-512), untrusted comments, trusted comments, timestamp, and anything else like if it is valid in green and to what public key it corresponds. Also should be easy for public key owners to publish the full Blake2b-512 hash of the key and allow the user to compare if the local public key get from them matches the hash they published.

The above is just making it "A dead simple tool to sign files and verify signatures." for the dumb users like me that see good potential on it but think is to hard to use with command lines.
There is a tool called "Xolido Sign Desktop" that is a good example of a simple GUI program, but with the advanced options that may be needed.

Future improvements suggestions:

1. Check online if that file signature was created by the author.
2. Allow users to get online timestamp from one or more different sources and add that information to the signature file.

More details on the above improvements suggestions...

1. Include a user online defined folder (in the author public key) where the program can go and check to see if the hash of the file is presented on the server with that name and if yes if the file inside includes the hash signed by that same public key.

Say for example: CheckURL:https://minisign.example.tld/
If the files has the Blake2b-512 hash: ba2632f6a9d30c1c1db6ad417210cd7dc21143467025b1b99853e41a14e94b15
Then the tool would go online and try to retrieve the same name file at: https://minisign.example.tld/ba2632f6a9d30c1c1db6ad417210cd7dc21143467025b1b99853e41a14e94b15 and verify if the file contains the hash sign by the same key.

For what? To make it harder for people that may steal the private key to sign files has being the other person without no one else notice anything.
The program must know that if the public key contains that optional parameter then all the files can only be completely trusted if the program can also get the online verification file, otherwise it may be spoofed.

These should make it harder for hacking while not depending in any third parties other than the one that the author of the public key already trusts.

2. It would be nice to have some sort of "universal minisign online timestamp server" ("minisign online timestamp"). UTC time based.

The local program would send the file hash to the "universal minisign online timestamp server" and would get back the hash sign with the server public key and timestamp of the operation.
Allow the use of other (multiple) services/ URLs. Other services/ URLs need their key to either be added manually by the user and/or to have the "minisign binary" updated to be trusted by default.
Online Timestamp source(s) needs to be displayed on the verification window together with the time data (year-month-day-hour-minutes-seconds).

For what? To help identify the precise time when the file was created from the "third party source", someone else other then the same person that produce the file.

Completely optional, disable by default, but visibly available for those for whom that can matter: song writers; song/ video publishers; software publishers; help proof someone has had that idea at that time, etc.

If you can't/ don't want to provide that online service I'm pretty sure a man in Spain that runs the service: https://www.freetsa.org will be more than happy to run that service on that server if it can be made in some format that he can adapt to the current server.

If something that can be easily be added to any dedicated/ VPS/ shared hosting is available like some PERL or PHP file with no special requirements other than put the file there I'm sure more online services can be made available. Maybe not the top notch trust, but hey more offers is better than less in these case... and if it gets widely adopted kind of "standard" big company's, organizations of all kinds, and governments may also provide "trusted and audited solutions" that they already provide for other things.

The timestamp server should keep a log of the hashes received and when they were received. To allow anyone to go there and see if they are in the database, if they have doubts (say: public key technology may have been broken, or something).
I saw one online web site claiming "Tamper-proof sequential validity chain ensures the integrity and credibility of the timestamp record" (http://truetimestamp.org) unfortunately while the concept explained on the page seems very simple (http://truetimestamp.org/img/sequential_fingerprints.png) it has forgot the access to the log database to be able to confirm the data... but is something that you can have in mind when creating some sort of solution if you really want.

Since these services may be pressed by governments / hacked to falsify the logs, the program needs to be allowed to submit the same hash to several services (defined by the user) at the same time and then get all the answers that are valid and add them to the same signature file.

Some sort of GUI interface to validate if the online timestamp(s) service(s) is(are) still available would be nice, to prevent contacting offline/ no longer available services.

For the users that don't need these functionality there is no problem since it is only used if they want it and use the proper options to get it.

But "we" can't trust anyone else argument... or "they" have to trust the public key owner about all the information provided.... except we are all the time trusting others in different degrees, these is one more way to allow that degree of trust about time information to be higher then just the self declaration that can be more bias the person own interests (several people having the same great idea may say they had that before the others... these helps them proof it beyond just their own words, from third parties that don't care about the issue, "neutral" in the matter). Not perfect, but good enough and can became better over time with more trustworthy institutions also support it (universities, banks, governments, non for profit organizations, for example).

Like WireGuard's wg pubkey.

Something like

minisign -S -t 'This short-message is protected.' -m /dev/null -x output.clearsig

, but without the untrusted comment: signature from minisign secret key\nRW...s=\n part at all, and without a file to verify.

This should produce short QR-code-able unforgeable messages, like gpg's --clearsign.

Is it possible that the char buffer in https://github.com/jedisct1/minisign/blob/master/src/base64.c#L77 is too short by one character? If I compile the code as C++ in -pedantic mode, gcc complains that the initializer string is too long. I would guess the compiler adds a zero-terminator at the end? However I'm not an expert for C, maybe there its different?

Please ignore my humble comment if C behaves different than C++ in this aspect.

Is there already a way to upload a .pub file to a trusted public key server? Would surely add some needed security layer.

Currently my package manager uses minisign in order to verify signatures on package metadata. In a future version, I would like to be able to download these into memory and verify without extra I/O. If this is too complicated, I can try using pipes instead (although this would be less efficient).

Could you let me know how I verify minisign before installing? I saw that earlier versions came with a .minisig file but that would mean installing minisign to check its minisig.

I could not find the .minisig for the latest version of minisign.

But I have noted that the libsodium tar comes with a .sig which can be verified outside minisign with gpg.

Could you let me know how to verify the minisign download I have as authentic; other than it comes from the 'right' HTTPS site?

Would be great to see the brew install minisign command also on ghpages (just a small suggestion).

Thx for minisign! :)

Heya, could we get the source releases signed too.

How to install minisign-0.6.tar.gz.minisig?
I can't extract the file :/

Please help, thanks!

Can't seem to get the command line syntax quite right. Trying to manually verify the latest dnscrypt-resolvers.csv.

I downloaded dnscrypt-resolvers.csv, dnscrypt-resolvers.csv.minisig, and minisign.pub into a folder. Trying the following commands do not work:
minisign -Vm dnscrypt-resolvers.csv -x dnscrypt-resolvers.csv.minisig
base64 conversion failed

minisign -Vm dnscrypt-resolvers.csv -p minisign.pub
base64 conversion failed

minisign -V -P "RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3" -m dnscrypt-resolvers.csv
Untrusted signature comment should start with "untrusted comment: "

I've read the documentation several times but am not sure what I'm doing wrong. Help appreciated, thanks!

Hi @jedisct1, can I submit a PR for provide docker support?

cat << 'EOF' | docker build -t minisign:0.8 -
FROM alpine:3.9 as build

WORKDIR /usr/src/minisign

RUN apk add --no-cache cmake make g++ libsodium-dev

RUN wget -O - https://github.com/jedisct1/minisign/archive/0.8.tar.gz | tar -xz --strip-components 1 && \
    mkdir build && cd build && \
    cmake .. && \
    make && make install


FROM alpine:3.9

RUN apk add --no-cache libsodium-dev

COPY --from=build /usr/local/bin/minisign /usr/local/bin/

ENTRYPOINT ["/usr/local/bin/minisign"]

EOF

Running:

docker run -it --rm minisign:0.8 -h

There is no .minisig for the 0.8 source code release tar. Could you add one?

(This as part of the ongoing work of using Minisign in Fedora, see https://lists.fedoraproject.org/archives/list/[email protected]/thread/WNR34OH3KVPKMGY4Z62CUPREEOVJJJNH/)

fyi: I have uploaded the first version of a script/workflow to verify files with minisign. minisign-sign will be added at a later date. (Edit: has been added now.)

https://github.com/JayBrown/minisign-misc

We need to get these packaged so we can debug things

For Windows x64...

I want to verify the only file so far I have obtained that came with a .minisig file. I bet this would be easier in linux but right now and for a little while I have to use windows 7 x64 ultimate.

I wanted to verify a downloaded file that is all about security (dnscrypt-proxy).

So I do minisign -G and then

C:\Users\generic\Downloads>minisign.exe -Vm "dnscrypt-proxy-win64-2.0.25.zip" -P
RWSrhtlidAACV5p0p84A8xMwgLUCwS9EorqVECrf8XHP2pJ+iSBlKWv1
Signature key id in dnscrypt-proxy-win64-2.0.25.zip.minisig is 79833371EA15D7E4
but the key id in the public key is 5702007462D986AB

That's not giving me confidence. Did I do anything wrong? I RTFM but I wanna verify (heh) with you before I go to the dnscrypt-proxy github to report this. Strangely using the .pub file plainly does not work. Thank you.

The CMake script executes with OK, but the make fails in Ubuntu 16.10. I'm guessing there is a version dependency problem. Ubuntu 16.10 provides gcc 6.2.0 and libsodium18 and its associated dev pkg (Ubuntu version 1.0.11-1). Attached is the log from the make.
build_log.txt

Hello,

i want to obtain the key, but it shown aborted, what wrong?

What about pre-built Linux binaries?

I think it would be nice if they are offered too.

To verify dnscrypt sources I've installed git version (today's build) of minisign.

Trying to execute command, recommended on https://github.com/jedisct1/dnscrypt-proxy/ failed with the following error message:

$ minisign -VP RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3 -m dnscrypt-proxy-1.9.4.tar.bz2
dnscrypt-proxy-1.9.4.tar.bz2.minisig: No such file or directory

I am trying to run my minisign the first time, but it failed with error: "kore-3.2.2.tar.gz.minisig: No such file or directory" from the following command:

$./minisign -Vm kore-3.2.2.tar.gz -P RWSxkEDc2y+whfKTmvhqs/YaFmEwblmvar7l6RXMjnu6o9tZW3LC0Hc9
kore-3.2.2.tar.gz.minisig: No such file or directory

$ echo $?
2
information about my environment:

$cat /proc/version
Linux version 4.18.16-300.fc29.x86_64 ([email protected]) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018

here is how I compiled minisign, which was downloaded from https://jedisct1.github.io/minisign/, note that I did NOT install it; I was running it from my ./build directory directly.
$ tar zxf jedisct1-minisign-0.8-3-g9eac49b.tar.gz

$ # ...
$ mkdir build
$ cd build
$ cmake ..

$ make -j2

Signify does not support keys without the "untrusted comment" header. I was hoping that minisign would do so, but in testing this I encountered a rather strange bug. Reproduce:

% openssl rand -base64 24 > fake.key
% openssl rand -base64 24 > data    
% minisign -Sm data -s fake.key      
fake.key: Success

Despite the output saying "success", the process is clearly not successful. Not only is no .minisig file created, this obviously couldn't work anyway since fake.key just contains garbage.

Using minisign 0.8.

As an aside, I think it would be nice to support files without the header. There's something unpleasant about requiring the files to contain a useless piece of information.

I'm writing a Dockerfile that installs dnscrypt and I thought it would be nice to install minisig beforehand to verify the signatures of minisig itself and dnscrypt.

To be sure minisig hasn't been tampered with I thought about including the .minisig of the source tarball, but neither 0.6 nor 0.7 seem to have a minisig in the releases tab.

I'm getting base64 conversion failed - was an actual public key given?, when providing a Public Key that was generated from libsodium.js

Example:
minisign -Vm doc.json -P ehWPtJODyfVgcuXwTJYg8AsQ6OORRNr1dKlYqxOq9CI=

Signature:
xHhQuYug4gPruQEeY1cvy3BoLSl59DdqMvpEiZks7derYzs7M7+EkFok+8Y3xY6mzQ1p/X3LZwN3OZy++F9SAA==

Message:
{"schema":"doc-x","version":1,"nonce":"612fbe9e-d115-4104-a539-7592f7fd4390","date":"2017-12-13T03:05:49+00:00","sub":{"a":"b","c":[1,2,3]}}

https://github.com/jedisct1/minisign/blob/master/src/minisign.h#L17

;-)

Scuttlebutt is a decentral message passing network (which also can and is used as a social network) that uses ed25519 keys as the core identifier of an identity. There was an idea to create signatures with this ed25519 key for the binaries of scuttlebutt clients. Can I pass my secret key which was created by scuttlebutt somehow to minisign? From reading the docs and the secret key format this seems rather complicated, because of all the key derivation stuff.

Thanks for your time and your great work with libsodium!

Hey, as of the documentation, the keynum_sk contains the <secret_key> and <public_key>. On the other side, checksum does only contain the <secret_key>. Probably <secret_key> means pub + sec, but it seems inconsistent to use it like this. Reading the code, the checksum is made over both, the public and the private key, right?

Signify supports verifying a signed checksum file and the files referenced by it. This is implemented via an inline signature at the top of a BSD format checksum file. On Linux, using coreutils, these can be generated by using sha256sum --tag followed by signing the result with signify -S -e. For verification, signify knows how to verify the hashes itself with -C rather than extracting them with signify -V -e and verifying them as a separate step. OpenBSD releases are signed this way, as an example: https://ftp.openbsd.org/pub/OpenBSD/6.5/SHA256.sig. It reports whether files are verified on a case-by-case basis after verifying the signature, and then the exit status is based on whether everything verified, with a missing file treated as an overall failure, although you can see from the output which files passed.

Since signify lacks support for the minisign pre-hash feature, I'm using this feature as a way of doing pre-hashing for large files that's compatible with signify. I don't really care about support for verifying multiple files from one signature. I'm using this approach for GrapheneOS to sign the factory images used for the initial install:

https://grapheneos.org/install#obtaining-factory-images
https://grapheneos.org/releases#stable-channel

You can see the example verify command that I'm giving in the instructions:

signify -Cqp factory.pub -x crosshatch-factory-2019.06.23.05.zip.sig && echo verified

I'm silencing the signify output since I feel that it's confusing, as it will output that the signature was verified even if the hashes are incorrect followed by giving output for each of the files. I think it should be clearer that it only verified the signature of the hashes, or omit that from the output completely as it's redundant. It only needs to report when signature verification fails, since it already has output for each of the files having a matching (signed) hash.

I'd like to be able to offer users the ability to verify these files with minisign as an alternative. It wouldn't make sense to provide a separate signature for minisign, as that would be counter to the goals of this being easy and straightforward.

OpenBSD may be willing to support pre-hashing directly, perhaps even in a way that's compatible with minisign, but it will be years before I can depend on any new features in signify thanks to frozen package versions in Linux distributions like Debian.

You may also want to consider more general support for signify's inline -e format messages embedded after the signature, but I only care about the specific case of signed checksum files. I also don't really care about the ability to sign multiple files, just support for pre-hashing a single file compatible with signify.

I'd understand if you didn't want to add this since you already have a more elegant approach for pre-hashing with a single file. I think there's a lot of value in broader signify compatibility though.

Is it possible to separate the comment sections with new (or break) lines or fill with "..." (if spaces not possible) the needless space for a new line, or anything like that?

"untrusted comment: here is your file............................................
trusted comment: file name,checksum,time-stamp,anything"

Or is there a solution for this already?

*with text editor looks good but a bit space between them would be nice, i close it, sorry.

It would be handy (when invoking minisign -V from a script, for example) if a different exit status were used to distinguish between "real" verification failures and other errors (argument error, nonexistent or unreadable file, base64 conversion failure, etc.).

For example, exit status 0 means verification succeeded (as it does today), 1 means verification failed (strictly), 2 means some other problem occurred.

See the cmp utility (on Ubuntu and OS X, at least) for an example of a program that distinguishes errors this way.

Thank you.

Heya,
minisign v0.5 is still v0.4 for the Windows build.

There's no actual code in the project's repo, and there's an issue that's been open for a while on the project asking for the status and pointing out that there's no code there. I think it's never actually had a release. Probably shouldn't list it as an implementation.

Experimenting with minisign I was a bit surprised to see that the keys generated are just dropped in the current dir. This also implies that the default usage of minisign would require the private key to be sitting in the same directory you are running minisign from and would need to be moved around or always specified with -s <seckey>.

While there is nothing really inherently wrong with this, it would be much more convenient if a default location, in addition to the current dir, was checked for keys. I would propose that minisign should, by default, create (with perms 700) and drop its keys in the ~/.minisign dir. If keys already exist it should warn and exit so as not to overwrite. minisign should complain and exit if the dir is not 0700 for security.

When running minisign to sign, or verify, it should look in that as a secondary default location (in addition to current dir) for keys.

You could kind of simulate this behavior today by storing the key files in any arbitrary dir and always passing in that path with the -s <seckey> option but this is kind of a pain to remember to do every time. You can't really fix it with an alias either since sometimes you need to pass in the secret key path, and sometimes the public key path, but not always both.

If you want to take this one step further. Have a ~/.minisignrc file (optional) that would allow the user a way to specify the default path where keys should be looked for instead of current dir or ~/.minisign. This would be useful if, for example, the keys lived on an external usb flash drive which is only connected when needed but would always mount to a known location.

Thanks!

I was just trying to port over minisign for my linux distro (Panux) and ran into a segmentation fault when trying to generate a key. Other things such as getting help and checking the version work.

To reproduce, run the following commands inside the panux alpha docker container panux/panux:alpha:

lpkg install minisign
export HOME=/root
minisign -G

I am not sure whether this is my problem or yours.

Build Information

Version: 0.7
Script used to build
Compiled packages

Note: Due to a bug, packages are not actually compressed. however this does not make a difference for this purpose.

Hi,

For the purposes of scripting, it would nice to have two extra argument options:

1. The ability to define a key with no password (for testing and/or non security-critical applications)

2. The ability to pass a key via command line or reference to a file or somesuch.