Checking for current date is added by knots patches. bitcoin-22.0.knots20211108_p3-features.patch: if (IsThisSoftwareExpired(GetTime())) { QMessageBox::critical(0, QObject::tr("Software expired"), QObject::tr("This software is expired, and may be out of consensus. You must choose to upgrade or override this expiration.")); return EXIT_FAILURE; } "-softwareexpiry 0" argument can be used for overriding expiration check. Reproducible: Always
Created attachment 846546 [details] ebuild for version 23.0
Created attachment 846548 [details] ebuild for secp256k1-0.2.0
Created attachment 846556 [details] update to version 23.0
https://twitter.com/LukeDashjr/status/1609937505217904642 says not to upgrade to newer knots.
(In reply to Sam James from comment #4) > https://twitter.com/LukeDashjr/status/1609937505217904642 says not to > upgrade to newer knots. May be better do not use knots.
Probably best to use 21.2 for now. libsecp256k1 cannot be simply bumped like that. There's a PR on gentoo/gentoo github if you want to have a go at it. It might also be in the bitcoin overlay. P.S. This bugzilla account has now been secured (changed password)
> P.S. This bugzilla account has now been secured (changed password) It's nothing personal (I have known you on IRC for years as joecool), but as you've been suffering repeated system compromises that you seem to not know the full extent of, I would strongly urge Gentoo to drop knots for now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b04090bf2211a537a56853b772faa70472e2c0a8 commit b04090bf2211a537a56853b772faa70472e2c0a8 Author: David Seifert <soap@gentoo.org> AuthorDate: 2023-01-04 21:33:54 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2023-01-04 21:33:54 +0000 profiles/base: mask bitcoin knots patchset Bug: https://bugs.gentoo.org/889326 Signed-off-by: David Seifert <soap@gentoo.org> profiles/base/package.use.mask | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
Masking [knots] for now seems reasonable, though there's no realistic risk since Gentoo has its own Manifests. But the improper bumping of libsecp256k1 that was apparently done is liable to create security issues and should probably be reverted.
(In reply to Luke-Jr from comment #9) > But the improper bumping of libsecp256k1 that was apparently done is liable > to create security issues and should probably be reverted. Improper how? Please describe the problem in full rather than making vague allegations.
Just to be clear: Gentoo only had Manifests for 21.2 and 22.0; so there's no safe way to bump it to 23.0 (even with a corrected libsecp256k1), only to retain the current versions.
Sam: Improper because of the incompatible ABI change, as I discussed with you previously. Review your IRC logs and the GitHub PR for the bump. I'm not in a situation where I can directly help with resolving this right now (seems like a bad time to be bumping things for no reason tbh).
(In reply to Luke-Jr from comment #12) > Sam: Improper because of the incompatible ABI change, as I discussed with > you previously. Review your IRC logs and the GitHub PR for the bump. I'm not > in a situation where I can directly help with resolving this right now > (seems like a bad time to be bumping things for no reason tbh). 1. The subslot was changed and the dependencies in older ebuilds fixed to be even more safe, but note that older Bitcoin ebuilds already had := (and actually fail to compile w/ newer libsecp) so there was never an issue there. 2. Not "no reason", Bitcoin was a year out of date. 3. The ebuild closely resembles what is in the bitcoin overlay?
fwiw though I'm unconvinced unbundling these essentially-internal libraries is a good idea going forward; they're obviously very brittle, and we gain very little (nothing?) from unbundling. Just harder to bump Bitcoin itself and open to risks of deviating from upstream or accidentally introducing a bug. All of this should really be documented in the ebuilds, too.
Just use bundled libsecp256k1 (and leveldb) with a new ebuild bitcoin-core? Currently bitcoin-qt, bitcoind, bitcoin-tx, and libbitcoinconsensus are all part of the same suite. The only other stuff that needs libsecp256k1 are some electron/electrum stuff (no relation to the better known electron). Can they just rely on a new bitcoin-core ebuild with a minimal number of useflags? Just thinking almost everything else in portage that has this situation had a useflag for qt for the qt interface. If people want bitcoin-tx, make it a useflag for bitcoin-core, same for the other items. It's nearly a decade old but blueness knows about this, maybe Sam should know: https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit?pli=1#heading=h.i7tz3gqh65mi Note the signatures were removed around the time of Luke's compromise but the web archive still has them: http://web.archive.org/web/20221224205226/http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc
(In reply to Joe Kappus from comment #15) > Just use bundled libsecp256k1 (and leveldb) with a new ebuild bitcoin-core? > Currently bitcoin-qt, bitcoind, bitcoin-tx, and libbitcoinconsensus are all > part of the same suite. The only other stuff that needs libsecp256k1 are > some electron/electrum stuff (no relation to the better known electron). Can > they just rely on a new bitcoin-core ebuild with a minimal number of > useflags? > > Just thinking almost everything else in portage that has this situation had > a useflag for qt for the qt interface. If people want bitcoin-tx, make it a > useflag for bitcoin-core, same for the other items. > > It's nearly a decade old but blueness knows about this, maybe Sam should > know: > https://docs.google.com/document/d/ > 1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit?pli=1#heading=h. > i7tz3gqh65mi > > Note the signatures were removed around the time of Luke's compromise but > the web archive still has them: > http://web.archive.org/web/20221224205226/http://luke.dashjr.org/tmp/code/ > 20130723-linux-distribution-packaging-and-bitcoin.md.asc I agree, but let's take it into a new bug.
