Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
Merged #1245 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#event-3385730799___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
Anyway, the DB discussion is a separate topic. Thanks for the doc review guys, fixed in the last push. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635775456___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
There's at least one thing that needs to be dealt with one way or the other before dropping BDB can be seriously considered: ``` [pmatilai︎lumikko rpm]$ grep %_db_backend macros.in %_db_backend bdb ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635773621___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@pmatilai pushed 1 commit. 294692aadac5c9723b022f6f3169d16139dc1a74 Remove support for NSS -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245/files/2786179da12033257d6f006046a2d0e443136bdf..294692aadac5c9723b022f6f3169d16139dc1a74 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@pmatilai commented on this pull request. > @@ -14,24 +14,13 @@ The source for the file utility + library is available > from ftp://ftp.astron.com/pub/file/ You will need a cryptographic library to support digests and signatures. -This library may be libgcrypt, Mozilla NSS, OpenSSL or beecrypt. +This library may be libgcrypt, Mozilla NSS or OpenSSL. Of course. Thanks for spotting. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#discussion_r432266248___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@Conan-Kudo requested changes on this pull request. > @@ -14,24 +14,13 @@ The source for the file utility + library is available > from ftp://ftp.astron.com/pub/file/ You will need a cryptographic library to support digests and signatures. -This library may be libgcrypt, Mozilla NSS, OpenSSL or beecrypt. +This library may be libgcrypt, Mozilla NSS or OpenSSL. This should be `libgcrypt or OpenSSL`, ne? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#pullrequestreview-420463401___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@Conan-Kudo approved this pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#pullrequestreview-420462821___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@pmatilai Come on, drop BDB! Go for the gold! 磊 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635586247___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@jessorensen commented on this pull request. > @@ -3,7 +3,8 @@ include $(top_srcdir)/rpm.am AM_CFLAGS = @RPMCFLAGS@ -AM_CPPFLAGS = -I$(top_builddir) -I$(top_srcdir) -I$(top_builddir)/include/ +AM_CPPFLAGS = -I$(top_builddir) -I$(top_srcdir) -I$(top_builddir)/include/ \ + -I$(includedir) It's gone -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431905464___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@jessorensen commented on this pull request. > + rpmlog(RPMLOG_DEBUG, "fsverity not supported by file system for > %s\n", + path); + break; + case EOPNOTSUPP: + rpmlog(RPMLOG_DEBUG, "fsverity not enabled on file system for %s\n", + path); + break; + case ETXTBSY: + rpmlog(RPMLOG_DEBUG, "file is open by other process %s\n", + path); + break; + default: + rpmlog(RPMLOG_DEBUG, "failed to enable verity (errno %i) for %s\n", + errno, path); + break; + } > Ignoring on unsupported filesystems is totally fine, that's exactly what we > do for SELinux (which is not supported on all filesystems either). There > might well be other specific errors where ignoring is the right thing to do, > but in general errors should be treated as such and fail the install, or at > least issue a warning that something might not be okay. OK, excuse my ignorance here. If I return RPMRC_FAIL for these, will it fail the installation of the package, or just spew warnings? I didn't want to get into a state where I had to check the file system for each file, before I enabled verity on the file. Do you prefer I return RPMRC_OK if it's not supported, but RPMRC_FAIL if it actually fails? I'll have to have another look at all the return values to make sure I have them covered correctly. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431905174___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@jessorensen commented on this pull request.
> if (deleting) { /* Nuke all the signature tags. */
deleteSigs(sigh);
+ deleteFileSigs(sigh);
> The IMA signatures originally were covered by package signature, but that
> breaks some fundamental rpm rules so it was changed in a latter release. So
> these days file signatures are entirely separate items, and can be added and
> removed without affecting others.
Sweet, I was under the assumption that they were covered, so didn't want to go
down that path. I'll have a look at adding this as a separate --delfilesigs
option. I think it's reasonable to delete all file signatures with one option,
IMA and fsverity, but I can also make it two, if you prefer.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431902614___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@jessorensen commented on this pull request.
> +}
+
+rpmlog(RPMLOG_DEBUG, _("key: %s\n"), key);
+rpmlog(RPMLOG_DEBUG, _("cert: %s\n"), cert);
+
+compr = headerGetString(h, RPMTAG_PAYLOADCOMPRESSOR);
+rpmio_flags = rstrscat(NULL, "r.", compr ? compr : "gzip", NULL);
+
+gzdi = Fdopen(fdDup(Fileno(fd)), rpmio_flags);
+free(rpmio_flags);
+if (!gzdi)
+ rpmlog(RPMLOG_DEBUG, _("Fdopen() failed\n"));
+
+files = rpmfilesNew(NULL, h, RPMTAG_BASENAMES, RPMFI_FLAGS_QUERY);
+fi = rpmfiNewArchiveReader(gzdi, files,
+ RPMFI_ITER_READ_ARCHIVE_OMIT_HARDLINKS);
> Right, silly me. I plead ignorance and amnesia on what little I know about
> the Merkle tree stuff... but now that you remind me, it makes me think
> there's quite a bit of mutual interest here.
>
> There are multiple places in rpm that would benefit from gradually verifiable
> content, starting with the file digests themselves. If rpm stored the Merkle
> hashes for the files at build time, I suppose you could then just sign those?
> And when available, rpm could use those instead of the traditional digests
> for its verify operation for quicker identification of modified content.
Yes that should be feasible, the traditional digest can be derived from the
Merkle tree. If we added support for rpm to use a Merkle tree internally that
would be a mutual benefit, since it allows one to verify a data block in linear
time without having to checksum the entire file. Note that the Merkle tree
consumes roughly 1/127 of the file size, so there is a cost with it, but it's
not crazy. It would be a fair amount of work on top of this, but maybe
something to put on the long term goal list?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431900804___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@jessorensen commented on this pull request.
> @@ -430,6 +438,10 @@ typedef enum rpmSigTag_e {
RPMSIGTAG_SHA256 = RPMTAG_SHA256HEADER,
RPMSIGTAG_FILESIGNATURES = RPMTAG_SIG_BASE + 18,
RPMSIGTAG_FILESIGNATURELENGTH = RPMTAG_SIG_BASE + 19,
+RPMSIGTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE + 20,
+RPMSIGTAG_VERITYSIGNATURELENGTH= RPMTAG_SIG_BASE + 21,
+RPMSIGTAG_VERITYSIGNATUREALGO = RPMTAG_SIG_BASE + 22,
+RPMSIGTAG_VERITYSIGNATUREBLKSZ = RPMTAG_SIG_BASE + 23,
> > Block size is a little tricky, as it depends on the file system block size,
> > which depending on the file system is either fixed or page size. I was
> > planning on adding option parameters to rpmsign allowing someone to specify
> > them for the case they want to build rpms on one platform to be installed
> > on another platform.
>
> Eek. This seems terrible from rpm POV.
>
> I mean, rpm's get built on some system somewhere, and signed on another, and
> then installed on wide variety of anything that we have zero control (or
> interest) over, data in rpms simply cannot be filesystem specific. Or
> page-size specific for that matter - while arch specific packages are
> obviously arch specific, a huge part of rpms are noarch where no such
> assumptions can be made.
>
> I get that on the kernel side the filesystem block / page size is the
> smallest unit that will be read in at once, but seems to me the verity block
> size should be hardwired to the lowest common denominator (something like 512
> or 1024) and verification on page-in looks at the data at that denominator
> size.
It's not pretty at all, I totally agree. The problem is that the kernel has to
hold the Merkle tree in memory while files are opened, so the smaller the block
size, the larger the memory footprint. The default should be PAGE_SIZE for
public packages, but I would like to retain this option for those who package
and maintain their own rpms, if that's OK with you?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431898002___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@jessorensen commented on this pull request.
> @@ -430,6 +438,10 @@ typedef enum rpmSigTag_e {
RPMSIGTAG_SHA256 = RPMTAG_SHA256HEADER,
RPMSIGTAG_FILESIGNATURES = RPMTAG_SIG_BASE + 18,
RPMSIGTAG_FILESIGNATURELENGTH = RPMTAG_SIG_BASE + 19,
+RPMSIGTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE + 20,
+RPMSIGTAG_VERITYSIGNATURELENGTH= RPMTAG_SIG_BASE + 21,
+RPMSIGTAG_VERITYSIGNATUREALGO = RPMTAG_SIG_BASE + 22,
+RPMSIGTAG_VERITYSIGNATUREBLKSZ = RPMTAG_SIG_BASE + 23,
> Yes. So you'd have:
>
> ```
> RPMTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE+24, /* s */
> [...]
> RPMSIGTAG_VERITYSIGNATURES = RPMTAG_VERITYSIGNATURES,
> ```
>
> ...and the similarly for the other tags.
>
> > With regard to the different tags, then for the signature length, it
> > depends on the key used and the algorithm. Are you suggesting we calculate
> > the length of the signature from the length of the signature array and
> > divide it by the number of entries?
>
> I'm not sure what I'm suggesting Storage size as such is not an issue, it's
> just that I find the length tag looking superfluous. Isn't it just "strlen()
> / 2" of the hex data - and once using base64, something you'll get from
> rpmBase64Decode(). It's not a value you need upfront, is it?
Oh that's an interesting point, I'll have a look at that with the base64 code.
If I can derive the size from that, that would be a great win.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431895475___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@pmatilai commented on this pull request. > Which library to use can be specified with the ---with-crypto=[libgcrypt|beecrypt|nss|openssl] argument to configure, +--with-crypto=[libgcrypt|nss|openssl] argument to configure, Oh, of course. Thanks for spotting! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#discussion_r431834471___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@voxik commented on this pull request. > Which library to use can be specified with the ---with-crypto=[libgcrypt|beecrypt|nss|openssl] argument to configure, +--with-crypto=[libgcrypt|nss|openssl] argument to configure, Shouldn't be the NSS references removed similarly to beecrypt? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#pullrequestreview-420103380___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@pmatilai oh, in that case - I would ditch bdb backend and possibly enable bdb_ro by default for 4.17 and then in 4.18 disable it by default. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635344736___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %toolchain macro to differentiate C/C++ toolchains (#1231)
Closed #1231. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1231#event-3382419186___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %toolchain macro to differentiate C/C++ toolchains (#1231)
We will solve this differently, in redhat-rpm-config. Thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1231#issuecomment-635291864___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
Actually BDB too is already marked deprecated in 4.16 (commit fc0169eb03c893d63dc44f2ada954d42e0e759ed) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635287573___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
@pmatilai I think we need to deprecate it in 4.17 and ditch it in 4.18 while keeping bdb_ro only. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635286229___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Preparing for rpm 4.16.0-beta1 (#1244)
Merged #1244 into rpm-4.16.x. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1244#event-3382355093___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
Flushing BDB down the same drain is really, really, really tempting :innocent: but maybe not *just* yet... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635280546___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
:rocket: :+1: -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245#issuecomment-635278798___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] macros: Drop internal macros which are not used in RPM and Fedora (#1212)
With 4.16 branched off now... thanks for the patch! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1212#issuecomment-635269858___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] macros: Drop internal macros which are not used in RPM and Fedora (#1212)
Merged #1212 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1212#event-3382243657___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove deprecated beecrypt and NSS crypto backends (#1245)
Shedding some weight to celebrate the beginning of a new cycle :fireworks: You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1245 -- Commit Summary -- * Bump version to mark beginning of a new development cycle * Remove support for beecrypt * Remove support for NSS -- File Changes -- M INSTALL (15) M Makefile.am (2) M build/Makefile.am (2) M configure.ac (65) M lib/Makefile.am (2) M rpm.pc.in (2) M rpmio/Makefile.am (20) D rpmio/digest_beecrypt.c (507) D rpmio/digest_nss.c (532) M sign/Makefile.am (2) M tests/rpmsigdig.at (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1245.patch https://github.com/rpm-software-management/rpm/pull/1245.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1245 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Preparing for rpm 4.16.0-beta1 (#1244)
Bump version number and adjust reproducable hash test accordingly. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1244 -- Commit Summary -- * Preparing for rpm 4.16.0-beta1 -- File Changes -- M configure.ac (2) M po/ar.po (678) M po/br.po (677) M po/ca.po (680) M po/cmn.po (680) M po/cs.po (680) M po/da.po (679) M po/de.po (680) M po/el.po (677) M po/eo.po (680) M po/es.po (680) M po/fi.po (0) M po/fr.po (0) M po/id.po (0) M po/is.po (0) M po/it.po (0) M po/ja.po (0) M po/ko.po (0) M po/ms.po (0) M po/nb.po (0) M po/nl.po (0) M po/pl.po (0) M po/pt.po (0) M po/pt_BR.po (0) M po/rpm.pot (0) M po/ru.po (0) M po/sk.po (0) M po/sl.po (0) M po/sr.po (0) M po/s...@latin.po (0) M po/sv.po (0) M po/te.po (0) M po/tr.po (0) M po/uk.po (0) M po/vi.po (0) M po/zh_CN.po (0) M po/zh_TW.po (0) M tests/rpmsigdig.at (0) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1244.patch https://github.com/rpm-software-management/rpm/pull/1244.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1244 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %postbuild section / Allow dynamic sub packages (#1239)
```
RPM build errors:
line 223: %package -n rust-libc-devel: package rust-libc-devel already
exists
fish: Job 2, “~/Projects/upstream/rpm/rpmbuil…” terminated by signal SIGSEGV
(Address boundary error)
```
Segfault if the package redefinition happens is not expected.
---
```
error: line 44: Too many names: %description -n rust-libc-devel %{_description}
```
It seems that the `%{_description}` macro is not getting expanded. But it is
defined in a spec.
---
And the last thing is that `%postbuild` gets executed during `rpmbuild -bs`
which can lead to very interesting problems when run in unclean environment.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1239#issuecomment-635219979___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request. > + rpmlog(RPMLOG_DEBUG, "fsverity not supported by file system for > %s\n", + path); + break; + case EOPNOTSUPP: + rpmlog(RPMLOG_DEBUG, "fsverity not enabled on file system for %s\n", + path); + break; + case ETXTBSY: + rpmlog(RPMLOG_DEBUG, "file is open by other process %s\n", + path); + break; + default: + rpmlog(RPMLOG_DEBUG, "failed to enable verity (errno %i) for %s\n", + errno, path); + break; + } Ignoring on unsupported filesystems is totally fine, that's exactly what we do for SELinux (which is not supported on all filesystems either). There might well be other specific errors where ignoring is the right thing to do, but in general errors should be treated as such and fail the install, or at least issue a warning that something might not be okay. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431687458___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Bump CI Fedora version from 31 to 32 aka latest stable (#1243)
Merged #1243 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1243#event-3381787330___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request.
> +}
+
+static char *rpmVeritySignFile(rpmfi fi, size_t *sig_size, char *key,
+ char *keypass, char *cert, uint16_t algo,
+ uint32_t block_size)
+{
+struct libfsverity_merkle_tree_params params;
+struct libfsverity_signature_params sig_params;
+struct libfsverity_digest *digest = NULL;
+rpm_loff_t file_size;
+char *digest_hex, *sig_hex = NULL;
+uint8_t *sig = NULL;
+int status;
+
+if (S_ISLNK(rpmfiFMode(fi)))
+ file_size = 0;
Ack.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431679634___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request.
> @@ -430,6 +438,10 @@ typedef enum rpmSigTag_e {
RPMSIGTAG_SHA256 = RPMTAG_SHA256HEADER,
RPMSIGTAG_FILESIGNATURES = RPMTAG_SIG_BASE + 18,
RPMSIGTAG_FILESIGNATURELENGTH = RPMTAG_SIG_BASE + 19,
+RPMSIGTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE + 20,
+RPMSIGTAG_VERITYSIGNATURELENGTH= RPMTAG_SIG_BASE + 21,
+RPMSIGTAG_VERITYSIGNATUREALGO = RPMTAG_SIG_BASE + 22,
+RPMSIGTAG_VERITYSIGNATUREBLKSZ = RPMTAG_SIG_BASE + 23,
> Block size is a little tricky, as it depends on the file system block size,
> which depending on the file system is either fixed or page size. I was
> planning on adding option parameters to rpmsign allowing someone to specify
> them for the case they want to build rpms on one platform to be installed on
> another platform.
Eek. This seems terrible from rpm POV.
I mean, rpm's get built on some system somewhere, and signed on another, and
then installed on wide variety of anything that we have zero control (or
interest) over, data in rpms simply cannot be filesystem specific. Or page-size
specific for that matter - while arch specific packages are obviously arch
specific, a huge part of rpms are noarch where no such assumptions can be made.
I get that on the kernel side the filesystem block / page size is the smallest
unit that will be read in at once, but seems to me the verity block size should
be hardwired to the lowest common denominator (something like 512 or 1024) and
verification on page-in looks at the data at that denominator size.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431678635___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request.
> @@ -430,6 +438,10 @@ typedef enum rpmSigTag_e {
RPMSIGTAG_SHA256 = RPMTAG_SHA256HEADER,
RPMSIGTAG_FILESIGNATURES = RPMTAG_SIG_BASE + 18,
RPMSIGTAG_FILESIGNATURELENGTH = RPMTAG_SIG_BASE + 19,
+RPMSIGTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE + 20,
+RPMSIGTAG_VERITYSIGNATURELENGTH= RPMTAG_SIG_BASE + 21,
+RPMSIGTAG_VERITYSIGNATUREALGO = RPMTAG_SIG_BASE + 22,
+RPMSIGTAG_VERITYSIGNATUREBLKSZ = RPMTAG_SIG_BASE + 23,
> So first question, you are suggesting I move the tags to the range of
> RPMTAG_SIG_BASE like this - just want to make sure I got it right:
RPMTAG_SHA256HEADER = RPMTAG_SIG_BASE+17, /* s */
Yes. So you'd have:
```
RPMTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE+24, /* s */
[...]
RPMSIGTAG_VERITYSIGNATURES = RPMTAG_VERITYSIGNATURES,
```
...and the similarly for the other tags.
> With regard to the different tags, then for the signature length, it depends
> on the key used and the algorithm. Are you suggesting we calculate the length
> of the signature from the length of the signature array and divide it by the
> number of entries?
I'm not sure what I'm suggesting :smile: Storage size as such is not an issue,
it's just that I find the length tag looking superfluous. Isn't it just
"strlen() / 2" of the hex data - and once using base64, something you'll get
from rpmBase64Decode(). It's not a value you need upfront, is it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431669436___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Bump CI Fedora version from 31 to 32 aka latest stable (#1243)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1243 -- Commit Summary -- * Bump CI Fedora version from 31 to 32 aka latest stable -- File Changes -- M ci/Dockerfile (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1243.patch https://github.com/rpm-software-management/rpm/pull/1243.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1243 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request.
> +}
+
+rpmlog(RPMLOG_DEBUG, _("key: %s\n"), key);
+rpmlog(RPMLOG_DEBUG, _("cert: %s\n"), cert);
+
+compr = headerGetString(h, RPMTAG_PAYLOADCOMPRESSOR);
+rpmio_flags = rstrscat(NULL, "r.", compr ? compr : "gzip", NULL);
+
+gzdi = Fdopen(fdDup(Fileno(fd)), rpmio_flags);
+free(rpmio_flags);
+if (!gzdi)
+ rpmlog(RPMLOG_DEBUG, _("Fdopen() failed\n"));
+
+files = rpmfilesNew(NULL, h, RPMTAG_BASENAMES, RPMFI_FLAGS_QUERY);
+fi = rpmfiNewArchiveReader(gzdi, files,
+ RPMFI_ITER_READ_ARCHIVE_OMIT_HARDLINKS);
Right, silly me. I plead ignorance and amnesia on what little I know about the
Merkle tree stuff... but now that you remind me, it makes me think there's
quite a bit of mutual interest here.
There are multiple places in rpm that would benefit from gradually verifiable
content, starting with the file digests themselves. If rpm stored the Merkle
hashes for the files at build time, I suppose you could then just sign those?
And when available, rpm could use those instead of the traditional digests for
its verify operation for quicker identification of modified content.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431652462___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request.
> if (deleting) { /* Nuke all the signature tags. */
deleteSigs(sigh);
+ deleteFileSigs(sigh);
The IMA signatures originally were covered by package signature, but that
breaks some fundamental rpm rules so it was changed in a latter release. So
these days file signatures are entirely separate items, and can be added and
removed without affecting others.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431638751___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %postbuild section / Allow dynamic sub packages (#1239)
@ffesti pushed 1 commit. 9b1a24a921f281747eb475276a3693471ee2b0b1 Add suppport for %postbuild spec section -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1239/files/23077b960b01e952ea6acc6596ad4b66bfbe534a..9b1a24a921f281747eb475276a3693471ee2b0b1 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request. > @@ -3,7 +3,8 @@ include $(top_srcdir)/rpm.am AM_CFLAGS = @RPMCFLAGS@ -AM_CPPFLAGS = -I$(top_builddir) -I$(top_srcdir) -I$(top_builddir)/include/ +AM_CPPFLAGS = -I$(top_builddir) -I$(top_srcdir) -I$(top_builddir)/include/ \ + -I$(includedir) Understood, the right way to do that is to pass CPPFLAGS=-I/some/path as an argument to ./configure. So yeah please drop it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431634790___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request.
> @@ -494,6 +505,36 @@ static rpmRC includeFileSignatures(Header *sigp, Header
> *hdrp)
#endif
}
+static rpmRC includeVeritySignatures(FD_t fd, Header *sigp, Header *hdrp)
+{
+#ifdef WITH_FSVERITY
+rpmRC rc;
+char *key = rpmExpand("%{?_file_signing_key}", NULL);
+char *keypass = rpmExpand("%{?_file_signing_key_password}", NULL);
+char *cert = rpmExpand("%{?_file_signing_cert}", NULL);
+
+if (rstreq(keypass, "")) {
+ free(keypass);
+ keypass = NULL;
+}
+
+if (key && cert) {
Oh, sorry, my bad. Weary eyes at the end of the day getting things mixed up, do
ignore.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431633575___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
