Re: [gentoo-dev] Guidance on distributed patented software
On 9/22/2021 12:37, Robin H. Johnson wrote: > On Wed, Sep 22, 2021 at 08:54:40AM -0400, Joshua Kinard wrote: >> Is there any advice on how this impacts net-misc/dropbear? That has ECC >> (both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images. >> The build doesn't have any bindist uses in it, and ECC support is a >> localoptions.h compile-time option (enabled by default). ECC is much faster >> on old SGI hardware and generating the hostkeys at bootup takes just a >> second or two, whereas RSA can take up to 10-15 seconds. So I'd like to be >> able to use ECC on these platforms and distribute netboot images using them. > RedHat doesn't seem to disable ECC in Dropbear: > https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec > > Based on what they've said for OpenSSL, I would expect that they SHOULD > have disabled ECC there, but there is certainly no consistency from > them. > > Probably nobody asked legal and just shipped dropbear anyway. > > If you wanted to stir the pot, you could post to the Fedora legal list > and ask for consistency ;-). Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions provided in libtomcrypt, and that library's homepage states all its code is public domain. Our ebuild has no bindist restrictions on that library. Perhaps that is how dropbear, and thus Red Hat, avoids the issues with licensing or patents? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
[gentoo-dev] [GLEP78] Updating specification r2
Hi, I attached second revision of the new draft of GLEP78 "Gentoo Binary Package Container Format" Please feel free to give any comments and suggestions. Thanks, Sheng Yu--- GLEP: 78 Title: Gentoo binary package container format Author: MichaŠGórny Sheng Yu Type: Standards Track Status: Draft Version: 1 Created: 2018-11-15 Last-Modified: 2021-09-22 Post-History: 2018-11-17, 2019-07-08, 2021-09-22 Content-Type: text/x-rst --- Abstract This GLEP proposes a new binary package container format for Gentoo. The current tbz2/XPAK format is shortly described, and its deficiences are explained. Accordingly, the requirements for a new format are set and a gpkg format satisfying them is proposed. The rationale for the design decisions is provided. Motivation == The current Portage binary package format - The historical ``.tbz2`` binary package format used by Portage is a concatenation of two distinct formats: header-oriented compressed .tar format (used to hold package files) and trailer-oriented custom XPAK format (used to hold metadata) [#MAN-XPAK]_. The format has already been extended incompatibly twice. The first time, support for storing multiple successive builds of binary package for a single ebuild version has been added. This feature relies on appending additional hyphen, followed by an integer to the package filename. It is disabled by default (preserving backwards compatibility) and controlled by ``binpkg-multi-instance`` feature. The second time, support for additional compression formats has been added. When format other than bzip2 is used, the ``.tbz2`` suffix is replaced by ``.xpak`` and Portage relies on magic bytes to detect compression used. For backwards compatibility, Portage still defaults to using bzip2; compression program can be switched using ``BINPKG_COMPRESS`` configuration variable. Additionally, there have been minor changes to the stored metadata and file storage policies. In particular, behavior regarding ``INSTALL_MASK``, controllable file compression and stripping has changed over time. The advantages of tbz2/XPAK format -- The tbz2/XPAK format used by Portage has three interesting features: 1. **Each binary package is fully contained within a single file.** While this might seem unnecessary, it makes it easier for the user to transfer binary packages without having to be concerned about finding all the necessary files to transfer. 2. **The binary packages are compatible with regular compressed tarballs, most of the time.** With notable exceptions of historical versions of pbzip2 and the recent zstd compressor, tbz2/XPAK packages can be extracted using regular tar utility with a compressor implementation that discards trailing garbage. 3. **The metadata is uncompressed, and can be efficiently accessed without decompressing package contents.** This includes the possibility of rewriting it (e.g. as a result of package moves) without the necessity of repacking the files. Transparency problem with the current binary package format --- Notwithstanding its advantages, the tbz2/XPAK format has a significant design fault that consists of two issues: 1. **The XPAK format is a custom binary format with explicit use of binary-encoded file offsets and field lengths.** As such, it is non-trivial to read or edit without specialized tools. Such tools are currently implemented separately from the package manager, as part of the portage-utils toolkit, written in C [#PORTAGE-UTILS]_. 2. **The tarball compatibility feature relies on obscure feature of ignoring trailing garbage in compressed files**. While this is implemented consistently in most of the compressors, this feature is not really a part of specification but rather traditional behavior. Given that the original reasons for this no longer apply, new compressor implementations are likely to miss support for this. Both of the issues make the format hard to use without dedicated tools, or when the tools misbehave. This impacts the following scenarios: A. **Using binary packages for system recovery.** In case of serious breakage, it is really preferable that the format depends on as few tools a possible, and especially not on Gentoo-specific tools. B. **Inspecting binary packages in detail exceeding standard package manager facilities.** C. **Modifying binary packages in ways not predicted by the package manager authors.** A real-life example of this is working around broken ``pkg_*`` phases which prevent the package from being installed. OpenPGP extensibility problem - There are at least three obvious ways in which the current format could be extended to support OpenPGP signatures, and each of them has its own distinct problem: 1. **Adding a
[gentoo-dev] Up for grabs: dev-cpp/rttr
Short-term dependency of kde-apps/kdenlive, now without revdeps. Last release in 2018, already takes 4 patches to build successfully. Low activity upstream, fails to build against GLIBC-2.34: https://bugs.gentoo.org/806508 This package is headed for treecleaning without a maintainer and fix. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
Finally it happened! I already planned to try to ask infra/council about sponsoring few servers for build farm for "official gentoo binhosts" when I had enough time, but fortunately, you've already did that. It's very good news. Btw, do you need any help with that? I'd be very happy to help with that project. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Guidance on distributed patented software
On Wed, Sep 22, 2021 at 08:54:40AM -0400, Joshua Kinard wrote: > Is there any advice on how this impacts net-misc/dropbear? That has ECC > (both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images. > The build doesn't have any bindist uses in it, and ECC support is a > localoptions.h compile-time option (enabled by default). ECC is much faster > on old SGI hardware and generating the hostkeys at bootup takes just a > second or two, whereas RSA can take up to 10-15 seconds. So I'd like to be > able to use ECC on these platforms and distribute netboot images using them. RedHat doesn't seem to disable ECC in Dropbear: https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec Based on what they've said for OpenSSL, I would expect that they SHOULD have disabled ECC there, but there is certainly no consistency from them. Probably nobody asked legal and just shipped dropbear anyway. If you wanted to stir the pot, you could post to the Fedora legal list and ask for consistency ;-). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] Guidance on distributed patented software
On 9/20/2021 14:15, Robin H. Johnson wrote: > On Mon, Sep 20, 2021 at 01:27:37PM -0400, Rich Freeman wrote: >> On Mon, Sep 20, 2021 at 12:46 PM Alec Warner wrote: >>> >>> Could we add some text to the license concepts covering patents? It >>> seems to have been omitted? >>> Is my understanding of how we manage patented software correct? >> >> I think you have the gist of it. Is there actually anything in the >> repo these days which is patent-encumbered? I realize this is a >> little tangential, but I think this is probably why we don't have a >> well-thought policy: it just doesn't come up much. > Elliptic Curve cryptography is the most topical & impactful thing I'm > aware of. > > RedHat have for many years stripped parts of it out of their OpenSSL & > libgcrypt packages, and continue to do it with OpenSSL-3 [1] (I note > that somebody has dropped these patches from Gentoo's openssl as of v3 > and I intend to restore them). > > RedHat's legal team clearly know something there that they aren't > disclosing the details of publicly, because the patches said the patents > expire in 2020, but when I asked off-list if EC could be re-enabled > based on the expiry dates in the files, they claimed that patent issues > were still present, without giving any detail. > > Somebody else ALSO asked about the Brainpool EC curves specifically and > similarly got nowhere [2]. > > [1] > https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide > [2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html > [snip] Is there any advice on how this impacts net-misc/dropbear? That has ECC (both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images. The build doesn't have any bindist uses in it, and ECC support is a localoptions.h compile-time option (enabled by default). ECC is much faster on old SGI hardware and generating the hostkeys at bootup takes just a second or two, whereas RSA can take up to 10-15 seconds. So I'd like to be able to use ECC on these platforms and distribute netboot images using them. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Experimental binary package hosting
Thanks! I never used an external binhost repo so mislead myself. Now I see that it's like a remote analogue of "/usr/portage/packages" and tarballs from remote binhost are fetched on demand into "local binhost" ( /usr/portage/packages/ ) before installation with replacing early presented tarballs. > binhost.conf should be in binrepos.conf instead of repos.conf. See also: > https://wiki.gentoo.org/wiki/Binary_package_guide#Pulling_packages_from_a_binary_package_host > A binhost is different from an ebuild repository, it is just a > collection of .xpak files so there is no git sync involved.
Re:[gentoo-dev] Experimental binary package hosting
Thanks. These settings are works. I just forgot to add USE="bindist" for tested dev-qt/qtwebengine package as mentioned early in mailing list. Great! Now no need to compile qtwebengine for hours next time! :)
Re: [gentoo-dev] Experimental binary package hosting
Am Mittwoch, 22. September 2021, 10:20:10 CEST schrieb Torokhov Sergey: > Sorry for previous html message. I tried to recend it as plaintext. > > I have repos configs placed into /etc/portage/repos.conf with > "rsync-type = git" fo all repos so I created binhost.cond file here > instead of /etc/portage/ as mentioned in blog post. Nope. As the blog post says, you need to put that text into a *file* with name -->>> /etc/portage/binrepos.conf <<<--- ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re:[gentoo-dev] Experimental binary package hosting
Sorry for previous html message. I tried to recend it as plaintext. I have repos configs placed into /etc/portage/repos.conf with "rsync-type = git" fo all repos so I created binhost.cond file here instead of /etc/portage/ as mentioned in blog post. Then I tried to sync and got warnings: ... !!! Section 'binhost' in repos.conf is missing location attribute !!! Repository 'binhost' has sync-uri attribute, but is missing sync-type attribute ... So it seems it's dosn't sync with binhost index without location attribute. After setup location attribute to specific directory I got warning on sync trying: !!! Repository 'binhost' has sync-uri attribute, but is missing sync-type attribute !!! Repository 'binhost' is missing masters attribute in '/usr/local/portage/binhost/metadata/layout.conf' !!! Set 'masters = gentoo' in this file for future compatibility I tried to set up "rsync-type = rsync" or "webrsync" with "amsters = gentoo" but then I got error: !!! Repository 'binhost' is missing masters attribute in '/usr/local/portage/binhost/metadata/layout.conf' !!! Set 'masters = gentoo' in this file for future compatibility So I created /usr/local/portage/binhost/metadata/layout.conf : masters = gentoo auto-sync = false thin-manifests = true So then on sync I got: The current sync-type attribute of repository 'gentoo' is not set to 'rsync' or 'webrsync': sync-type=git Is it currently git sync available for binhost?
Re: [gentoo-dev] Experimental binary package hosting
On 22/09/2021 09:58, Torokhov Sergey wrote: I have repos configs placed into /etc/portage/repos.conf with "rsync-type = git" fo all repos so I created binhost.cond file here instead of /etc/portage/ as mentioned in blog post. binhost.conf should be in binrepos.conf instead of repos.conf. See also: https://wiki.gentoo.org/wiki/Binary_package_guide#Pulling_packages_from_a_binary_package_host Then I tried to sync and got warnings: ... !!! Section 'binhost' in repos.conf is missing location attribute !!! Repository 'binhost' has sync-uri attribute, but is missing sync-type attribute ... So it seems it's dosn't sync with binhost index without location attribute. After setup location attribute to specific directory I got warning on sync trying: !!! Repository 'binhost' has sync-uri attribute, but is missing sync-type attribute !!! Repository 'binhost' is missing masters attribute in '/usr/local/portage/binhost/metadata/layout.conf' !!! Set 'masters = gentoo' in this file for future compatibility I tried to set up "rsync-type = rsync" or "webrsync" with "amsters = gentoo" but then I got error: !!! Repository 'binhost' is missing masters attribute in '/usr/local/portage/binhost/metadata/layout.conf' !!! Set 'masters = gentoo' in this file for future compatibility So I created /usr/local/portage/binhost/metadata/layout.conf : masters = gentoo auto-sync = false thin-manifests = true So then on sync I got: The current sync-type attribute of repository 'gentoo' is not set to 'rsync' or 'webrsync': sync-type=git Is it currently git sync available for binhost? A binhost is different from an ebuild repository, it is just a collection of .xpak files so there is no git sync involved.
Re: [gentoo-dev] Experimental binary package hosting
I have repos configs placed into /etc/portage/repos.conf with "rsync-type = git" fo all reposso I created binhost.cond file here instead of /etc/portage/ as mentioned in blog post. Then I tried to sync and got warnings:...!!! Section 'binhost' in repos.conf is missing location attribute !!! Repository 'binhost' has sync-uri attribute, but is missing sync-type attribute... So it seems it's dosn't sync with binhost index without location attribute. After setup location attribute to specific directory I got warning on sync trying:!!! Repository 'binhost' has sync-uri attribute, but is missing sync-type attribute !!! Repository 'binhost' is missing masters attribute in '/usr/local/portage/binhost/metadata/layout.conf'!!! Set 'masters = gentoo' in this file for future compatibility I tried to set up "rsync-type = rsync" or "webrsync" with "amsters = gentoo" but then I got error:!!! Repository 'binhost' is missing masters attribute in '/usr/local/portage/binhost/metadata/layout.conf' !!! Set 'masters = gentoo' in this file for future compatibility So I created /usr/local/portage/binhost/metadata/layout.conf :masters = gentoo auto-sync = falsethin-manifests = trueSo then on sync I got: The current sync-type attribute of repository 'gentoo' is not set to 'rsync' or 'webrsync': sync-type=git Is it currently git sync available for binhost?21.09.2021, 20:22, "Andreas K. Huettel" :So let's experiment with this... :) announcing:https://gentoo.osuosl.org/experimental/amd64/binpkg/default/linux/17.1/x86-64/More information can be found in a blog post, which will also be on planet.g.osoon:https://dilfridge.blogspot.com/2021/09/experimental-binary-gentoo-package.htmlCheers -A --Andreas K. Hütteldilfri...@gentoo.orgGentoo Linux developer(council, qa, toolchain, base-system, perl, libreoffice)
