Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
I have pushed an updated patchset into the repo. I think it addresses everything we discussed, including getting rid of the LENGTH and BLKSZ tags, adding the --delfilesign option to rpmsign, and switches to base64 encoding. Let me know if you find anything else that needs addressing or if I messed up and forgot something. The changes to fsverity-utils went into the official tree earlier this week, so just waiting for a new release to be tagged before I can push an update into rawhide. -- 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#issuecomment-636215427___ 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; + } I went through this and changed it to return RPMRC_FAIL for all cases, except for the error cases where fsverity is not enabled or supported by the file system. I think it's fair to fail hard and ugly for the cases where the signature is malformed etc. -- 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_r432761349___ 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,
OK I see your point. It isn't unreasonable to count on page size for this and
mandate that it is up to the file system to cope if the file system block size
and page size don't match. I will take out this tag.
I also have the base64 encoding/decoding working now, which allowed me to get
rid of the signature length tag.
--
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_r432724168___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Approved: l10n: zh_TW: update translation (#1237)
@pan93412 pushed 1 commit. 78286c9d5044a53c16f7669764b31fbd36797788 l10n: zh_TW: fix the issues in translation -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1237/files/9b056de66b76cace442440d51b618a56310f2f69..78286c9d5044a53c16f7669764b31fbd36797788 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
Ah, I forgot that he talked about it too. -- 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/329#issuecomment-635976924___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
no Florian gave a talk about it. https://media.ccc.de/v/2501-re-thinking-spec-files -- 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/329#issuecomment-635973588___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
It is the thing that @ignatenkobrain and I were talking about last year, yes. -- 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/329#issuecomment-635972856___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
Isn't this basically the template idea that was presented at the opensuse conference in 2019? -- 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/329#issuecomment-635971284___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
cc: @hroncok This is something we should look toward for next-gen Python packaging stuff. -- 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/329#issuecomment-635866347___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
cc: @scarabeusiv @darix @coolo This could be relevant for subpackage generation for Ruby and Python in openSUSE/SLE. -- 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/329#issuecomment-635865633___ 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; + } Returning FAIL here will fail the package install (which isn't pretty, but sometimes necessary). The exact semantics of when its okay to ignore failure are case-dependent and subject to debate and often practical experiences too. I think it's unreasonable to expect getting this 100% right from the go, consider this feedback more of a guideline than specific demands: silencing and/or ignoring an error should always be an exception to the rule. -- 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_r432348210___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Announcing POPT upstream reboot and 1.18 release candidate (DRAFT)
At the time of the rpm.org upstream reboot back in 2006 [1], the idea was to split out popt from the rpm codebase and then ... something. Only we were too busy dealing with rpm itself and popt got left behind. The last popt release is from 2010 and about a year ago it's download site dropped off the net. People have been prodding us about this for some time now, popt being a mandatory dependency of rpm but also used by several other prominent OSS projects such as Samba, SSSD and Gnome. So after heroic efforts of Neal Gompa to convert the rusty old CVS (anybody still remember *that* horror?) repo into a nice shiny git repo, here goes. From now on, popt will be maintained under the rpm-software-management umbrella at https://github.com/rpm-software-management/popt where bugs can be reported and pull-requests submitted, with release tarball on ftp.rpm.org. To accompany the launch there's also a new 1.18 release in the pipeline: http://ftp.rpm.org/releases/testing/popt-1.18-rc1.tar.gz [2] Much like with rpm itself back in the day, this first release is all about collecting existing fixes and cleaning up the codebase, starting with the last widely used 1.16 release as the basis. There are no new features in this release or in the immediate plans, time will tell where this all will lead. There will be a release notes page for the final release, but for now the executive summary of changes is: - fix an ugly and ancient security issue with popt failing to drop privileges on alias exec from a SUID/SGID program - perform rudimentary sanity checks when reading in popt config files - collect accumulated misc fixes from distros etc - dust off ten years worth of autotools sediment - reorganize and clean up the source tree for clarity - remove the obnoxious splint annotations from the sources 1.18-rc1 is supposed to be ABI and API compatible with 1.16, and unless something unexpected happens, will be released as 1.18 final within a month or so. If you can, give it a spin and let us know. On behalf of the rpm-team, - Panu - [1] http://lists.rpm.org/pipermail/rpm-announce/2006-December/05.html [2] SHA256: 2ba1769489e6eddb6b2969d4de5e8fc855fb668c411d8bc002042c14708e682c ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] RPM 4.16.0 beta1 released!
The gap between alpha and beta was longer than usual because we were waiting for bug reports for the new sqlite backend from wider exposure in Fedora. After two months, we figured we can't wait forever. Zero filed bugs is almost certainly too good to be entirely true, but it's a not a bad situation either. In the meanwhile, on top of the usual assorted fixes and minor enhancements, the highligh since the alpha is that rpm expressions gained native version comparison powers and new version parsing and comparison API was added to C and Python. Download info and the usual, including updated details and examples on the new expression capabilities of 4.16 at: https://rpm.org/wiki/Releases/4.16.0 Enjoy! On behalf of rpm-team, - Panu - ___ 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);
Yeah, having a single option for both types of file signatures should be plenty.
--
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_r432294404___
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);
Ok, good to know.
Absolutely not expecting any such work to be part of this effort, just musing
about possibilities. It's useful to be at least aware of the
possibilities/consequences from the go.
--
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_r432291739___
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,
Allowing for options (eg at distro level) is not the issue, the real issue is
that for this to be a generally meaningful feature for rpm at all, these
signatures need to be architecture and filesystem independent. For rpm it's all
the same whether the block size is big or small as long as its consistent
across all architectures, we can't have essentially arch-specific signatures in
a noarch package. So this seems like quite a deal-breaker to me, unless I'm
misunderstanding something (which is certainly possible).
--
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_r432288920___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
