public inbox for goredo-devel@lists.stargrave.org Atom feed
* [PATCH] REDO_SHELL sets which shell goredo uses @ 2026-10-13 16:02 ser.goredo=ser1.net via 2026-10-13 16:02 ` [PATCH] REDO_SHELL sets which shell goredo uses. Some OSes change which shell /bin/sh points to; on Arch, it's bash. On Debian (on some forks, at least), it's dash. These shells are incompatible, esp about topics like variable expansion. With REDO_SHELL, users can set which shell goredo forks and ensure builds run ser.goredo=ser1.net via 2026-10-14 14:05 ` [PATCH] REDO_SHELL sets which shell goredo uses Sergey Matveev (stargrave=stargrave.org) via 0 siblings, 2 replies; 8+ messages in thread From: ser.goredo=ser1.net via @ 2026-10-13 16:02 UTC (permalink / raw) To: goredo-devel Hi, /bin/sh is not the same shell on all systems, and this can lead to non-trivial `do` files failing on different machines. On Arch, /bin/sh is a symlink to bash; on FuriOS (a mobile Debian distribution) it's symlinked to dash; on many embedded systems, it's busybox (ash). dash and bash are not compatible, especially in variable expansion, which can cause builds to fail across systems. This patch adds a `REDO_SHELL` environment variable. If set, goredo will use that executable as the shell it forks; otherwise, it will default to `/bin/sh`. That is, this patch should be backwards compatible while allowing builds to function without distribution-specific modification. I didn't see anywhere in the repos where the environment variables are documented, so there's no change that adds documentation. I think it's documented only on the website? main.go | 3 +++ run.go | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) --- SER ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] REDO_SHELL sets which shell goredo uses. Some OSes change which shell /bin/sh points to; on Arch, it's bash. On Debian (on some forks, at least), it's dash. These shells are incompatible, esp about topics like variable expansion. With REDO_SHELL, users can set which shell goredo forks and ensure builds run. 2026-10-13 16:02 [PATCH] REDO_SHELL sets which shell goredo uses ser.goredo=ser1.net via @ 2026-10-13 16:02 ` ser.goredo=ser1.net via 2026-10-14 14:05 ` [PATCH] REDO_SHELL sets which shell goredo uses Sergey Matveev (stargrave=stargrave.org) via 1 sibling, 0 replies; 8+ messages in thread From: ser.goredo=ser1.net via @ 2026-10-13 16:02 UTC (permalink / raw) To: goredo-devel From: "Sean E. Russell" <ser@ser1•net> --- main.go | 3 +++ run.go | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/main.go b/main.go index 9bd7766..9c10a75 100644 --- a/main.go +++ b/main.go @@ -223,6 +223,9 @@ func main() { default: log.Fatalln("unknown", EnvInodeTrust, "value") } + if os.Getenv(EnvShell) != "" { + Shell = os.Getenv(EnvShell) + } // Those are internal envs FdOODTgts, err = os.CreateTemp("", "ood-tgts") diff --git a/run.go b/run.go index 3f19556..8ab764c 100644 --- a/run.go +++ b/run.go @@ -54,6 +54,7 @@ const ( EnvStderrSilent = "REDO_SILENT" EnvNoSync = "REDO_NO_SYNC" EnvStopIfMod = "REDO_STOP_IF_MODIFIED" + EnvShell = "REDO_SHELL" RedoDir = ".redo" LockSuffix = ".lock" @@ -72,6 +73,7 @@ var ( Jobs sync.WaitGroup TmpsToClean = make(map[string]struct{}) TmpsToCleanM sync.Mutex + Shell = "/bin/sh" flagTrace *bool flagTraceAll *bool @@ -391,7 +393,7 @@ func runScript(tgt *Tgt, errs chan error, forced, traced bool) error { cmdName = doFile.a args = make([]string, 0, 3) } else { - cmdName = "/bin/sh" + cmdName = Shell if traced || TracedAll { args = append(args, "-ex") } else { -- 2.56.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] REDO_SHELL sets which shell goredo uses 2026-10-13 16:02 [PATCH] REDO_SHELL sets which shell goredo uses ser.goredo=ser1.net via 2026-10-13 16:02 ` [PATCH] REDO_SHELL sets which shell goredo uses. Some OSes change which shell /bin/sh points to; on Arch, it's bash. On Debian (on some forks, at least), it's dash. These shells are incompatible, esp about topics like variable expansion. With REDO_SHELL, users can set which shell goredo forks and ensure builds run ser.goredo=ser1.net via @ 2026-10-14 14:05 ` Sergey Matveev (stargrave=stargrave.org) via 2026-10-14 16:08 ` "Sean E. Russell" (ser.goredo=ser1.net) via 1 sibling, 1 reply; 8+ messages in thread From: Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-14 14:05 UTC (permalink / raw) To: goredo-devel [-- Attachment #1: Type: text/plain, Size: 2128 bytes --] Greetings! *** ser.goredo=ser1.net via [2026-10-13 09:02]: >/bin/sh is not the same shell on all systems, and this can lead to non-trivial >`do` files failing on different machines. On POSIX systems /bin/sh is expected to be POSIX compatible. If one writes a shell script, then it must be POSIX one. It should behave on all POSIX-compatible systems the same way. >On Arch, /bin/sh is a symlink to bash; >on FuriOS (a mobile Debian distribution) it's symlinked to dash; on many >embedded systems, it's busybox (ash). dash and bash are not compatible, >especially in variable expansion, which can cause builds to fail across systems. This is wrong. All those ash/bash/dash, even zsh, are compatible if running script is POSIX one. Of course, there may be differences in exact POSIX/SUS supported version (only relatively recently POSIX defined setopt pipefail, which is not supported by older dash versions (for example)). If someone writes not the (POSIX) shell script, but bash one, then he should explicitly set proper shebang line in it (also making it executable). bash-script (for example) is not a shell-script, because later is expected to be POSIX (shell) compatible. >This patch adds a `REDO_SHELL` environment variable. I think that this is very wrong, when people write non-POSIX compatible scripts and call them "shell scripts", which are expected to be run under whatever /bin/sh. But at least that REDO_SHELL could be useful for debugging purposes, to check those shell scripts workability under different implementations. Applied it. Thank you! >I didn't see anywhere in the repos where the environment variables are >documented, so there's no change that adds documentation. I think it's >documented only on the website? Website is just a HTML rendered doc/ subdirectory. There is doc/Env file, which will render all backlinks to that page, which are generated with "A [Env] REDO_...^M" lines on other pages. I mentioned REDO_SHELL on http://www.goredo.stargrave.org/cmd/EnvCommon.html page now. -- * Origin: Stargrave's homepage http://www.stargrave.org/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 265 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] REDO_SHELL sets which shell goredo uses 2026-10-14 14:05 ` [PATCH] REDO_SHELL sets which shell goredo uses Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-14 16:08 ` "Sean E. Russell" (ser.goredo=ser1.net) via 2026-10-16 8:43 ` Sergey Matveev (stargrave=stargrave.org) via 2026-10-16 9:37 ` Authenticating the tarballs and website Sergey Matveev (stargrave=stargrave.org) via 0 siblings, 2 replies; 8+ messages in thread From: "Sean E. Russell" (ser.goredo=ser1.net) via @ 2026-10-14 16:08 UTC (permalink / raw) To: Sergey Matveev (stargrave=stargrave.org) via On Wed Oct 14, 2026 at 7:05 AM PDT, Sergey Matveev (stargrave=stargrave.org) via wrote: > *** ser.goredo=ser1.net via [2026-10-13 09:02]: >>/bin/sh is not the same shell on all systems, and this can lead to non-trivial >>`do` files failing on different machines. > > On POSIX systems /bin/sh is expected to be POSIX compatible. > If one writes a shell script, then it must be POSIX one. It > should behave on all POSIX-compatible systems the same way. Hmm. Ok, so my bash substitutions, which I thought were POSIX, are not. TBH, I've been using Linux since 1995 but I don't believe I've ever used raw POSIX sh -- always csh, bash, or zsh -- so TIL. >>This patch adds a `REDO_SHELL` environment variable. > > I think that this is very wrong, when people write non-POSIX compatible Fair enough. Shebang at the beginning of every .do file works, although it's tedious, especially with redo which tends to explode *.do files. > under whatever /bin/sh. But at least that REDO_SHELL could be useful for > debugging purposes, to check those shell scripts workability under > different implementations. Applied it. Thank you! I was just in `t/` trying to figure out how to add unit tests for the thing; there's a few new technologies I need to learn about, like sharness, first. >>I didn't see anywhere in the repos where the environment variables are ... > Website is just a HTML rendered doc/ subdirectory. There is doc/Env Ah! Excellent. Thanks, I missed that. BTW, the Arch package for goredo was still pointing at the www.goredo.cypherpunks.su page, which hasn't been accessible for a bit. I asked that they rehome it to the new location -- what with all the AUR attacks, there's some nervousness about changing upstream. Is there any way to verify your new keys with some old one so people can feel confident that you're the same developer? The discussion is going on here: https://aur.archlinux.org/packages/goredo --- SER Sean E. Russell (https://ser1.net) OpMsg: https://ser1.net/.well-known/opmsg.txt GPG key: https://ser1.net/.well-known/pgp.asc Minisign: https://ser1.net/.well-known/minisign.pub Age: age195vpft7nzsy83medxagqqsge0lrcuf9txe3z2znlu2wsk69cdu4sx8nfvp ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] REDO_SHELL sets which shell goredo uses 2026-10-14 16:08 ` "Sean E. Russell" (ser.goredo=ser1.net) via @ 2026-10-16 8:43 ` Sergey Matveev (stargrave=stargrave.org) via 2026-10-16 9:37 ` Authenticating the tarballs and website Sergey Matveev (stargrave=stargrave.org) via 1 sibling, 0 replies; 8+ messages in thread From: Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-16 8:43 UTC (permalink / raw) To: "Sean E. Russell" (ser.goredo=ser1.net) via [-- Attachment #1: Type: text/plain, Size: 1172 bytes --] *** "Sean E. Russell" (ser.goredo=ser1.net) via [2026-10-14 09:08]: >Hmm. Ok, so my bash substitutions, which I thought were POSIX, are not. TBH, >I've been using Linux since 1995 but I don't believe I've ever used raw POSIX sh >-- always csh, bash, or zsh -- so TIL. I think most people use those kind of shells for interactive purposes. But ((POSIX) shell) scripts are different things, of course. Personally I use zsh, write some "#!/usr/bin/env zsh"-shebanged scripts for convenience, but have to use "#!/bin/sh" to write portable POSIX ones. Debian is a well-known distribution that started to actively clean out so-called shell scripts, which were in fact full of bash-isms (so dash, checkbashisms utilities were created). ALT Linux was another one, which was aggressive in that task. >Fair enough. Shebang at the beginning of every .do file works, although it's >tedious, especially with redo which tends to explode *.do files. Definitely. So if user is aware that he is writing non-POSIX .do scripts, but willing to do so for convenience, REDO_SHELL would be indeed helpful. -- * Origin: Stargrave's homepage http://www.stargrave.org/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 265 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Authenticating the tarballs and website 2026-10-14 16:08 ` "Sean E. Russell" (ser.goredo=ser1.net) via 2026-10-16 8:43 ` Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-16 9:37 ` Sergey Matveev (stargrave=stargrave.org) via 2026-10-16 23:20 ` "Sean E. Russell" (ser=ser1.net) via 1 sibling, 1 reply; 8+ messages in thread From: Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-16 9:37 UTC (permalink / raw) To: goredo-devel [-- Attachment #1: Type: text/plain, Size: 8415 bytes --] *** "Sean E. Russell" (ser.goredo=ser1.net) via [2026-10-14 09:08]: >BTW, the Arch package for goredo was still pointing at the >www.goredo.cypherpunks.su page, which hasn't been accessible for a bit. Yes, as I notified in http://lists.stargrave.org/archive/goredo-devel/Zp5G-1Cv4PtlJXd4@stargrave.org/T/ cypherpunks.ru was moved to cypherpunks.su, hoping that upcoming (at those times) law would not affect .su domain, and then moved to stargrave.org, because .su was also required to have esia.gosuslugi.ru-based authorisation pass. I do not want to have an account in that service (it requires running non-free software and a cellphone number binding). At the same time I can not use Western-based registrars, because of political complications and loss of trust to them: using their services is a pure lottery and bans, revocations are done without any notification as a rule, completely unexpectedly. So I still use Russian-based registrar, but non-ru/рф/su (and related ones, like .moscow, etc) domains (currently?) do not require esia-service authorisation. >I asked that they rehome it to the new location Thank you! >what with all the AUR attacks, there's some nervousness about changing upstream. Understandable. >Is there any way to verify your new keys with some old one so people >can feel confident that you're the same developer? Of course there is ability to make a trusted chain. * before 2023-08-08 I used to sign tarball with the PUBKEY.asc key: pub ed25519/0x3A528DDE952C7E93 2021-01-09 [SC] 7531BB84FAF0BF35960C63B93A528DDE952C7E93 uid [ ultimativ ] goredo releases <goredo@cypherpunks•su> uid [ ultimativ ] goredo releases <goredo@cypherpunks•ru> which was signed by my main PGP key (which signs all mail messages now) * later I started to sign tarballs with OpenSSH ed25519 (PUBKEY-SSH.pub) key. It was signed (PUBKEY-SSH.pub.asc) by my main key * since 2026-01-16 I included PUBKEY-CM.pub{,.asc} KEKS/CM public key which also signed the tarballs with SLH-DSA. I understand that virtually noone uses it (http://www.keks.stargrave.org/cm/index.html) and its format changed several times since then. Currently that is just for your interest :-) * OpenSSH added ssh-mldsa44-ed25519@openssh•com signature support and in 2026-07-06 I changed ed25519 key * recently they replaced ssh-mldsa44-ed25519@openssh•com with ssh-mldsa44-ed25519 (incompatibly), so I had to change it again. That was my fault of using experimental ("@openssh.com") key, which lead to those inconveniences * but all those OpenSSH keys were always signed by my main PGP key (which will sign that message too): pub ed25519/0xCB8205632107AD8A 2022-07-24 [C] 12AD32689C660D426967FD75CB8205632107AD8A uid [ ultimativ ] Sergey Matveev <stargrave@stargrave•org> uid [ ultimativ ] Sergey Matveev <stargrave@gnupg•net> uid [ niemals ] [jpeg image of size 5969] sub ed25519/0xD2237E8409086CB7 2022-07-24 [S] DB2FF8ED440A7E94986FB776D2237E8409086CB7 sub cv25519/0xAD1D959393A4B1E8 2022-07-24 [E] 8E144575F4B780F7479216E8AD1D959393A4B1E8 sub ky768_cv25519/0x59C57477918E09F8 2024-09-12 [E] 59C57477918E09F89A86DE2864979BB0C7A488F31B1A95A83CA3F57D0796FAAC * and that key was signed by my previous one: pub dsa3072/0xAE1A8109E49857EF 2010-08-12 [SC] CF60E89A59231E76E2636422AE1A8109E49857EF uid [ ultimativ ] Sergey Matveev <stargrave@stargrave•org> uid [ ultimativ ] Sergey Matveev <stargrave@gnupg•net> uid [ ultimativ ] Sergey Matveev <admin@cypherpunks•ru> sub elg3072/0x4E5984773E333450 2010-08-12 [E] 5A1F675EB6285C8438471D4B4E5984773E333450 sub rsa4096/0x1E1EC4456B350BA5 2012-01-22 [S] 229355B0F6DBFA721155BBC61E1EC4456B350BA5 sub rsa4096/0xCDEB6955365884FA 2012-01-22 [E] DAC871F621909B674BD8F024CDEB6955365884FA which contains various signatures from people I met on PGP keysigning parties, including Richard M. Stallman one (I redacted nearly all names for privacy reasons, although all that information is publicly available on most keyservers): % gpg --keyring ~/.gnupg/cryptoparty.kbx --check-sigs myold pub dsa3072/0xAE1A8109E49857EF 2010-08-12 [SC] CF60E89A59231E76E2636422AE1A8109E49857EF uid [ ultimativ ] Sergey Matveev <stargrave@stargrave•org> sig!3 0xAE1A8109E49857EF 2021-06-03 [Eigenbeglaubigung] sig! 0x0DF8A5CF9D51A4FC 2016-08-22 Georgii [...] sig! 0x13FEFBDD3D24E6BB 2014-08-02 Alexander [...] sig! 0x16D2A18030B46353 2010-08-12 Sergey Matveev (stargrave) <stargravesm@gmail•com> sig! 0x356BA5E24DF27D7B 2016-11-27 Nekolyanich [...] sig!3 0x357D886DFCCE9431 2015-07-04 Marie [...] sig! 1 0x48EA4BE97A579BFD 2017-08-19 [User-ID nicht gefunden] sig!3 0x4EDAD24AAFE81937 2013-12-18 Mikhail [...] sig! 0x59BF89FA47378873 2013-06-19 Morozov [...] sig!3 0x5B89C7585CA1EB8A 2016-08-20 Aleksei [...] sig!3 0x5CD7202EEF88F772 2014-08-03 Valdik[...] sig! 0x624DC565135EA668 2011-12-02 Richard Stallman (Chief GNUisance) <rms@gnu•org> sig! 0x6B787B1E10D954E9 2016-08-22 Georgii [...] sig!3 X 0x6C44C4C074F63CF8 2014-08-02 Dmitry [...] sig! 0x788BE01254B7F00D 2016-08-20 Dmitry [...] sig! 0x7C03A5858E0FE4AA 2019-12-09 Elena [...] sig! 0x97A31C55C76E2A61 2019-05-20 Elena [...] sig!3 0xA7F996948BAD1C8B 2015-12-06 [...] sig! 0xAC9CB9926DDFA43B 2010-12-06 Vladimir [...] sig! 0xBBACA7BC4D5E4BA9 2016-08-20 Oleg [...] sig! 0xC542A58D220C0270 2014-08-02 Ivan [...] sig! 0xCB8205632107AD8A 2022-07-24 Sergey Matveev <stargrave@stargrave•org> sig! 0xD0402DD332161842 2014-08-02 Vitaly [...] sig! 0xD351C68666E256E6 2016-08-21 Tatiana [...] sig!3 0xDE504C15D098D624 2016-08-20 Gleb [...] sig! 0xE0ACD3E0CBE7874A 2016-08-20 Ineiev [...] sig!3 0xE1F2A9807F50FAB2 2016-08-21 Leonid [...] sig!3 0xE5015B4F87C80EC9 2013-12-18 Dmitry [...] sig! 0xED699E1BDC3CB25C 2016-08-20 Anton [...] sig! 0xF845313106916116 2016-08-20 Владимир [...] So you should be able to start the trust chain from Richard M. Stallman for example, check my older PGP key, check current PGP key's signature, check OpenSSH'es keys (taken from git://git.stargrave.org/goredo.git or anongit@master•git.stargrave.org:stargrave.org/goredo.git or anongit@slave•git.stargrave.org:stargrave.org/goredo.git or tarballs, or saved email messages from the maillist with the keys fingerprints) signature and use them to check tarballs signatures. http://www.stargrave.org/TrustAnchor.html contains http://www.stargrave.org/keys/fpr.txt with PGP signature using my both older and newer keys: http://www.stargrave.org/keys/fpr.txt.asc It contains DNSCurve keys presented in DNS NS records, which can be used to authenticate my DNS server replies for stargrave.org zone. It also contains my CA X.509 fingerprint, as https://www.goredo.stargrave.org is using it. It also contains hashes of the SSH server's used to share Git source code above. Also there is signed Yggdrasil's address space 322:3bd:cc26:9545::/64 where all my websites also should be accessible (http://y.www.goredo.stargrave.org/). Obviously I can not use Let's Encrypt or any other by-default trusted X.509 CAs for HTTPS, as all of them are under NATO/USA control (or have limited use-cases (for banking for example)) and users from sanctioned countries/organisations are practically forbidden. And moreover of course they can not give any authenticity of the domain, as MitM was already practically possible: https://notes.valdikss.org.ru/jabber.ru-mitm/ And there is also https://goredo.dabase.com/ mirror, kindly provided by Kai Hendry, which is rsync-ed over SSH, explicitly asking my OpenSSH fingerprints beforehand. -- * Origin: Stargrave's homepage http://www.stargrave.org/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 265 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Authenticating the tarballs and website 2026-10-16 9:37 ` Authenticating the tarballs and website Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-16 23:20 ` "Sean E. Russell" (ser=ser1.net) via 2026-10-17 7:02 ` Sergey Matveev (stargrave=stargrave.org) via 0 siblings, 1 reply; 8+ messages in thread From: "Sean E. Russell" (ser=ser1.net) via @ 2026-10-16 23:20 UTC (permalink / raw) To: Sergey Matveev (stargrave=stargrave.org) via Hi Sergey, I'm CC'ing Hendry, who's the AUR maintainer of the package. Because it's a CC, I'm leaving most of your message intact rather than trimming it down. On Fri Oct 16, 2026 at 2:37 AM PDT, Sergey Matveev (stargrave=stargrave.org) via wrote: > *** "Sean E. Russell" (ser.goredo=ser1.net) via [2026-10-14 09:08]: >>BTW, the Arch package for goredo was still pointing at the >>www.goredo.cypherpunks.su page, which hasn't been accessible for a bit. > > Yes, as I notified in > http://lists.stargrave.org/archive/goredo-devel/Zp5G-1Cv4PtlJXd4@stargrave.org/T/ > cypherpunks.ru was moved to cypherpunks.su, hoping that upcoming (at > those times) law would not affect .su domain, and then moved to stargrave.org, > because .su was also required to have esia.gosuslugi.ru-based authorisation > pass. I do not want to have an account in that service (it requires running > non-free software and a cellphone number binding). At the same time I can Understandable! > not use Western-based registrars, because of political complications and > loss of trust to them: using their services is a pure lottery and bans, > revocations are done without any notification as a rule, completely > unexpectedly. So I still use Russian-based registrar, but non-ru/рф/su > (and related ones, like .moscow, etc) domains (currently?) do not > require esia-service authorisation. > >>I asked that they rehome it to the new location > > Thank you! > >>what with all the AUR attacks, there's some nervousness about changing upstream. > > Understandable. > >>Is there any way to verify your new keys with some old one so people >>can feel confident that you're the same developer? Sergey, your PGP key in the public keystores does not include anything but your self-sign. You might want to refresh it, especially if you have a signature from Stallman. Hendry, I don't think it matters for our purposes whether we can build a web of trust on the PGP key, since you're already including it in the 2.9.1 AUR PKGBUILD. If we validate the signature on the new signing key, we should be able to trust the new upstream as much as we trusted 2.9.1. Right? So, Hendry -- can we ensure ourselves of the continution of ownership of the upstream sources, and update the AUR package to point to the new home? Here are the steps I used: ``` # Clone upstream repo, which contains keys git clone --depth 1 git://git.stargrave.org/goredo.git cd goredo # Fetch the original PGP key (hash in the current 2.9.1 AUR package) gpg --receive-keys 7531BB84FAF0BF35960C63B93A528DDE952C7E93 # Validate the signature on the SSH key in the repo gpg --verify PUBKEY-SSH.pub.asc ``` This should be sufficient to assert a connection from the PGP key to the new signing key. To validate the new 2.10.0 tarball: ``` GOREDO_VERSION=2.10.0 # Fetch the source and sig for the current release curl -LO http://www.goredo.stargrave.org/download/goredo-${GOREDO_VERSION}.tar.zst curl -LO http://www.goredo.stargrave.org/download/goredo-${GOREDO_VERSION}.tar.zst.sig # Validate the tarball using the (now validated) SSH key ssh-keygen -Y verify -f PUBKEY-SSH.pub -I goredo@stargrave•org -n file \ -s goredo-${GOREDO_VERSION}.tar.zst.sig <goredo-${GOREDO_VERSION}.tar.zst ``` Sergey, I can't verify your tarball sig with openssh 10.6p1, which is what Arch users have. I get an unknown or unsupported key type. If your sigs require a newer ssh than that, they won't be useful for software distributed through AUR for now. Here's the information in the rest of the email Sergey provided if you want to forge your own journey. > Of course there is ability to make a trusted chain. > > * before 2023-08-08 I used to sign tarball with the PUBKEY.asc key: > > pub ed25519/0x3A528DDE952C7E93 2021-01-09 [SC] > 7531BB84FAF0BF35960C63B93A528DDE952C7E93 > uid [ ultimativ ] goredo releases <goredo@cypherpunks•su> > uid [ ultimativ ] goredo releases <goredo@cypherpunks•ru> > > which was signed by my main PGP key (which signs all mail messages now) > * later I started to sign tarballs with OpenSSH ed25519 (PUBKEY-SSH.pub) > key. It was signed (PUBKEY-SSH.pub.asc) by my main key > * since 2026-01-16 I included PUBKEY-CM.pub{,.asc} KEKS/CM public key > which also signed the tarballs with SLH-DSA. I understand that virtually > noone uses it (http://www.keks.stargrave.org/cm/index.html) and its > format changed several times since then. Currently that is just for > your interest :-) > * OpenSSH added ssh-mldsa44-ed25519@openssh•com signature support and in > 2026-07-06 I changed ed25519 key > * recently they replaced ssh-mldsa44-ed25519@openssh•com with > ssh-mldsa44-ed25519 (incompatibly), so I had to change it again. That > was my fault of using experimental ("@openssh.com") key, which lead to > those inconveniences > * but all those OpenSSH keys were always signed by my main PGP key > (which will sign that message too): > > pub ed25519/0xCB8205632107AD8A 2022-07-24 [C] > 12AD32689C660D426967FD75CB8205632107AD8A > uid [ ultimativ ] Sergey Matveev <stargrave@stargrave•org> > uid [ ultimativ ] Sergey Matveev <stargrave@gnupg•net> > uid [ niemals ] [jpeg image of size 5969] > sub ed25519/0xD2237E8409086CB7 2022-07-24 [S] > DB2FF8ED440A7E94986FB776D2237E8409086CB7 > sub cv25519/0xAD1D959393A4B1E8 2022-07-24 [E] > 8E144575F4B780F7479216E8AD1D959393A4B1E8 > sub ky768_cv25519/0x59C57477918E09F8 2024-09-12 [E] > 59C57477918E09F89A86DE2864979BB0C7A488F31B1A95A83CA3F57D0796FAAC > > * and that key was signed by my previous one: > > pub dsa3072/0xAE1A8109E49857EF 2010-08-12 [SC] > CF60E89A59231E76E2636422AE1A8109E49857EF > uid [ ultimativ ] Sergey Matveev <stargrave@stargrave•org> > uid [ ultimativ ] Sergey Matveev <stargrave@gnupg•net> > uid [ ultimativ ] Sergey Matveev <admin@cypherpunks•ru> > sub elg3072/0x4E5984773E333450 2010-08-12 [E] > 5A1F675EB6285C8438471D4B4E5984773E333450 > sub rsa4096/0x1E1EC4456B350BA5 2012-01-22 [S] > 229355B0F6DBFA721155BBC61E1EC4456B350BA5 > sub rsa4096/0xCDEB6955365884FA 2012-01-22 [E] > DAC871F621909B674BD8F024CDEB6955365884FA > > which contains various signatures from people I met on PGP keysigning > parties, including Richard M. Stallman one (I redacted nearly all > names for privacy reasons, although all that information is publicly > available on most keyservers): > > % gpg --keyring ~/.gnupg/cryptoparty.kbx --check-sigs myold > pub dsa3072/0xAE1A8109E49857EF 2010-08-12 [SC] > CF60E89A59231E76E2636422AE1A8109E49857EF > uid [ ultimativ ] Sergey Matveev <stargrave@stargrave•org> > sig!3 0xAE1A8109E49857EF 2021-06-03 [Eigenbeglaubigung] > sig! 0x0DF8A5CF9D51A4FC 2016-08-22 Georgii [...] > sig! 0x13FEFBDD3D24E6BB 2014-08-02 Alexander [...] > sig! 0x16D2A18030B46353 2010-08-12 Sergey Matveev (stargrave) <stargravesm@gmail•com> > sig! 0x356BA5E24DF27D7B 2016-11-27 Nekolyanich [...] > sig!3 0x357D886DFCCE9431 2015-07-04 Marie [...] > sig! 1 0x48EA4BE97A579BFD 2017-08-19 [User-ID nicht gefunden] > sig!3 0x4EDAD24AAFE81937 2013-12-18 Mikhail [...] > sig! 0x59BF89FA47378873 2013-06-19 Morozov [...] > sig!3 0x5B89C7585CA1EB8A 2016-08-20 Aleksei [...] > sig!3 0x5CD7202EEF88F772 2014-08-03 Valdik[...] > sig! 0x624DC565135EA668 2011-12-02 Richard Stallman (Chief GNUisance) <rms@gnu•org> > sig! 0x6B787B1E10D954E9 2016-08-22 Georgii [...] > sig!3 X 0x6C44C4C074F63CF8 2014-08-02 Dmitry [...] > sig! 0x788BE01254B7F00D 2016-08-20 Dmitry [...] > sig! 0x7C03A5858E0FE4AA 2019-12-09 Elena [...] > sig! 0x97A31C55C76E2A61 2019-05-20 Elena [...] > sig!3 0xA7F996948BAD1C8B 2015-12-06 [...] > sig! 0xAC9CB9926DDFA43B 2010-02-06 Vladimir [...] > sig! 0xBBACA7BC4D5E4BA9 2016-08-20 Oleg [...] > sig! 0xC542A58D220C0270 2014-08-02 Ivan [...] > sig! 0xCB8205632107AD8A 2022-07-24 Sergey Matveev <stargrave@stargrave•org> > sig! 0xD0402DD332161842 2014-08-02 Vitaly [...] > sig! 0xD351C68666E256E6 2016-08-21 Tatiana [...] > sig!3 0xDE504C15D098D624 2016-08-20 Gleb [...] > sig! 0xE0ACD3E0CBE7874A 2016-08-20 Ineiev [...] > sig!3 0xE1F2A9807F50FAB2 2016-08-21 Leonid [...] > sig!3 0xE5015B4F87C80EC9 2013-12-18 Dmitry [...] > sig! 0xED699E1BDC3CB25C 2016-08-20 Anton [...] > sig! 0xF845313106916116 2016-08-20 Владимир [...] > > So you should be able to start the trust chain from Richard M. Stallman > for example, check my older PGP key, check current PGP key's signature, > check OpenSSH'es keys (taken from git://git.stargrave.org/goredo.git or > anongit@master•git.stargrave.org:stargrave.org/goredo.git or > anongit@slave•git.stargrave.org:stargrave.org/goredo.git or > tarballs, or saved email messages from the maillist with the keys > fingerprints) signature and use them to check tarballs signatures. > > http://www.stargrave.org/TrustAnchor.html contains > http://www.stargrave.org/keys/fpr.txt > with PGP signature using my both older and newer keys: > http://www.stargrave.org/keys/fpr.txt.asc > It contains DNSCurve keys presented in DNS NS records, which can be used > to authenticate my DNS server replies for stargrave.org zone. It also > contains my CA X.509 fingerprint, as https://www.goredo.stargrave.org is > using it. It also contains hashes of the SSH server's used to share Git > source code above. Also there is signed Yggdrasil's address space > 322:3bd:cc26:9545::/64 where all my websites also should be accessible > (http://y.www.goredo.stargrave.org/). > > Obviously I can not use Let's Encrypt or any other by-default trusted > X.509 CAs for HTTPS, as all of them are under NATO/USA control (or have > limited use-cases (for banking for example)) and users from sanctioned > countries/organisations are practically forbidden. And moreover of > course they can not give any authenticity of the domain, as MitM was > already practically possible: https://notes.valdikss.org.ru/jabber.ru-mitm/ > > And there is also https://goredo.dabase.com/ mirror, kindly provided by > Kai Hendry, which is rsync-ed over SSH, explicitly asking my OpenSSH > fingerprints beforehand. --- SER Sean E. Russell (https://ser1.net) OpMsg: https://ser1.net/.well-known/opmsg.txt GPG key: https://ser1.net/.well-known/pgp.asc Minisign: https://ser1.net/.well-known/minisign.pub Age: age195vpft7nzsy83medxagqqsge0lrcuf9txe3z2znlu2wsk69cdu4sx8nfvp ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Authenticating the tarballs and website 2026-10-16 23:20 ` "Sean E. Russell" (ser=ser1.net) via @ 2026-10-17 7:02 ` Sergey Matveev (stargrave=stargrave.org) via 0 siblings, 0 replies; 8+ messages in thread From: Sergey Matveev (stargrave=stargrave.org) via @ 2026-10-17 7:02 UTC (permalink / raw) To: goredo-devel; +Cc: hendry [-- Attachment #1: Type: text/plain, Size: 1839 bytes --] *** "Sean E. Russell" [2026-10-16 16:20]: >Sergey, your PGP key in the public keystores does not include anything but your >self-sign. You might want to refresh it, especially if you have a signature from >Stallman. Ooops, indeed everything is missing on two keyservers I checked. According to https://keys.openpgp.org/about/faq/ third-party signatures are not included by default because of spam. Indeed I remember that there were serious issues with that. Well... that means that keyservers are useless now for full public keys distribution. Completely forgot about that. So the only option is to download it via WKD (which URL is included in my mail headers): http://openpgpkey.stargrave.org/.well-known/openpgpkey/stargrave.org/hu/s8kd45yyt8ymu6uttefkjkngyagsui5x.asc Actually WKD requires the use of HTTPS, but one suppose to have common trust anchors in that world? In my opinion that was very short-sighted decision. >Sergey, I can't verify your tarball sig with openssh 10.6p1, which is what Arch >users have. I get an unknown or unsupported key type. If your sigs require a newer >ssh than that, they won't be useful for software distributed through AUR for now. My bad, I forgot to re-sign all tarballs with the latest OpenSSH key, which was updated 2026-10-09 from ssh-mldsa44-ed25519@openssh•com to ssh-mldsa44-ed25519 algorithm. Currently it was not included in any tarballs, as no releases were made since that time. Just reuploaded all *.sig files. OpenSSH 10.6p1 is exactly the minimal version to check them. That key can be got either from Git repository, or http://www.goredo.stargrave.org/PUBKEY-SSH.pub http://www.goredo.stargrave.org/PUBKEY-SSH.pub.asc (as described on http://www.goredo.stargrave.org/Integrity.html) -- * Origin: Stargrave's homepage http://www.stargrave.org/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 265 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-10-17 7:02 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-10-13 16:02 [PATCH] REDO_SHELL sets which shell goredo uses ser.goredo=ser1.net via 2026-10-13 16:02 ` [PATCH] REDO_SHELL sets which shell goredo uses. Some OSes change which shell /bin/sh points to; on Arch, it's bash. On Debian (on some forks, at least), it's dash. These shells are incompatible, esp about topics like variable expansion. With REDO_SHELL, users can set which shell goredo forks and ensure builds run ser.goredo=ser1.net via 2026-10-14 14:05 ` [PATCH] REDO_SHELL sets which shell goredo uses Sergey Matveev (stargrave=stargrave.org) via 2026-10-14 16:08 ` "Sean E. Russell" (ser.goredo=ser1.net) via 2026-10-16 8:43 ` Sergey Matveev (stargrave=stargrave.org) via 2026-10-16 9:37 ` Authenticating the tarballs and website Sergey Matveev (stargrave=stargrave.org) via 2026-10-16 23:20 ` "Sean E. Russell" (ser=ser1.net) via 2026-10-17 7:02 ` Sergey Matveev (stargrave=stargrave.org) via