public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: "\"Sean E. Russell\" (ser=ser1.net) via" <goredo-devel@lists.stargrave.org>
To: "Sergey Matveev (stargrave=stargrave.org) via"
<goredo-devel@lists.stargrave.org>
Subject: Re: Authenticating the tarballs and website
Date: Fri, 16 Oct 2026 16:20:13 -0700 [thread overview]
Message-ID: <DM6NBWBCW5EN.29HPS0MMGSVZZ@ser1.net> (raw)
In-Reply-To: <atHwdIiShE6ljqDb@stargrave.org>
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
next prev parent reply other threads:[~2026-10-16 23:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2026-10-17 7:02 ` Sergey Matveev (stargrave=stargrave.org) via