[gentoo-dev] [PATCH] savedconfig.eclass: drop faulty permissions check
This check was meant to test if the user has accidentally restricted
access to the /etc/portage/savedconfig directory. There are a few
problems:
1. We don't actually need read access on the directory. We really need
the execute bit set so that we can access files within the directory.
2. There may be permissions issues on subdirectories, and we would fail
to detect them.
3. There is no easy way to distingish between EACCES and ENOENT using
shell commands. We get an exit status of 1 from [[ -r ${path} ]] if
there is a permissions problem or if some component of the path does
not exist. This makes resolving problem 2 difficult without using a
more robust language with direct access to errno.
Instead of trying to detect a permissions problem, just output a warning
telling the user to check permissions if we cannot find a config file.
Bug: https://bugs.gentoo.org/289168
Bug: https://bugs.gentoo.org/814995
Signed-off-by: Mike Gilbert
---
eclass/savedconfig.eclass | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index e90a9b618d6..c4fd0c492f4 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: savedconfig.eclass
@@ -146,14 +146,10 @@ restore_config() {
treecopy . "${dest}" || die "Failed to restore ${found} to $1"
popd > /dev/null
else
- # maybe the user is screwing around with perms they shouldnt
#289168
- if [[ ! -r ${base} ]] ; then
- eerror "Unable to read ${base} -- please check its
permissions."
- die "Reading config files failed"
- fi
ewarn "No saved config to restore - please remove
USE=savedconfig or"
ewarn "provide a configuration file in
${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"
- ewarn "Your config file(s) will not be used this time"
+ ewarn "and ensure the build process has permission to access
it."
+ ewarn "Your config file(s) will not be used this time."
fi
}
--
2.33.0
Re: [gentoo-dev] Guidance on distributed patented software
> On 25 Sep 2021, at 20:44, Joshua Kinard wrote:
>
>> [snip]
>>
>> ECDSA and the NIST curves have been around since > 20 years, so it's
>> simply impossible that there are any valid patents covering those.
>> (There is of course a slight possibility that there may be patents
>> covering specific implementation details of ECDSA/NIST curves that were
>> only described later.)
>
> Then we are either A) being too paranoid and should just drop bindist from
> the OpenSSL ebuilds, or B) we are not being paranoid enough and packages
> like dropbear/libtomcrypt need bindist added, no? It seems we're stuck in
> the middle here because we don't have the right information. If Red Hat or
> IBM are being non-responsive over this, then surely some other distro out
> there has already figured things out?
>
Agreed.
Furthermore, it's not clear to me that Debian or Ubuntu are "hobbling"
their OpenSSL implementations. I may have missed something, but I
don't see anything in:
- https://salsa.debian.org/debian/openssl/-/tree/debian/unstable/debian/patches
(or the rules file)
-
https://git.launchpad.net/ubuntu/+source/openssl/tree/debian/patches?h=applied/ubuntu/impish
(or the rules file)
The only thing I have found is an old bug report for Ubuntu
(https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/597984)
referencing disabling some non-EC parts.
>
>> I'm not entirely sure what you'd like to ask the libtomcrypt authors.
>> "We think there may be patents, but we don't know. Did you consider
>> that?"
>
> No, actually, I was thinking something more along the lines of "Hey, are you
> aware of these supposed patent claims about ECC/ECDSA implementations that
> Red Hat says exist, and if so, did you do any research on them that you
> could possibly share that led you to feeling confident to release your
> implementation into the public domain".
I'd like to make some points about our continued use of the "hobble" patch
for at least < OpenSSL 3 too:
- RH won't publicly say what they're worried about wrt EC in OpenSSL. This
could be to
avoid patent trolls, but this isn't really consistent with the patch being
"enough"
to protect them - or us - anyway?
- We don't know what patents the Fedora patch is allegedly preventing us
from infringing.
- If Fedora's patch is based on legal advice, there's no reason to believe
that it necessarily applies to us.
- We have no way of verifying the correctness (or completeness) of the Fedora
patch we use because it is unclear what it is protecting against.
- Even the latest version of Fedora's hobble patch _script_ only references
patents expiring, at the latest, in 2020:
https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl.
And, as you observed, this doesn't appear to be applied consistently anyway.
Dropbear
in Fedora appears to allow EC.
Right now, I'm far more concerned about the possible security impact of
applying patches whose correctness is not vouched for, nor do we truly
understand their purpose.
In addition, some of the changes in our current OpenSSL 1.1.x patches are
fragile
and easily mis-applied or mis-rebased. Here's an example of such a possibly
problematic hunk:
@@ -2026,9 +1945,9 @@ int speed_main(int argc, char **argv)
# endif
# ifndef OPENSSL_NO_EC
-ecdsa_c[R_EC_P160][0] = count / 1000;
-ecdsa_c[R_EC_P160][1] = count / 1000 / 2;
-for (i = R_EC_P192; i <= R_EC_P521; i++) {
+ecdsa_c[R_EC_P224][0] = count / 1000;
+ecdsa_c[R_EC_P224][1] = count / 1000 / 2;
+for (i = R_EC_P256; i <= R_EC_P521; i++) {
ecdsa_c[i][0] = ecdsa_c[i - 1][0] / 2;
ecdsa_c[i][1] = ecdsa_c[i - 1][1] / 2;
if (ecdsa_doit[i] <= 1 && ecdsa_c[i][0] == 0)
@@ -2040,7 +1959,7 @@ int speed_main(int argc, char **argv)
}
}
}
-# ifndef OPENSSL_NO_EC2M
+# if 0
By not using easy macros where possible, we're making it far easier to have
compile-time
or even runtime errors.
>
> But I am open to better language. I just don't wanna sit here not knowing.
> Someone out there has to have the right information to settle this.
>
Yep. We consult legal advice or stop using half-measures.
Best,
sam
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-dev] Guidance on distributed patented software
On Sun, Sep 26, 2021 at 1:09 PM Peter Stuge wrote: > > There's not neccessarily a conflict between a patented idea and a > public domain implementation of that idea. It kind of depends on what you mean by "conflict." > > Take a fictional example: > > You and I independently invent the same thing. You patent it, then > write and publish an LGPL implementation. I, ignorant of your > accomplishment, later write and publish a different implementation, > placing it in the public domain. > > You having a patent doesn't neccessarily matter to me publishing my > implementation. Sure it does. Depending on the claims of the patent, your publication of the completely independent implementation is basically a public confession that you violated the original patent. Now, if you didn't obtain any commercial value from it and were ignorant it is pretty unlikely that somebody would actually go after you for it or get damages, but you can infringe on a patent while being completely ignorant of it and doing all your own independent work. The patent covers the idea, no matter how many times it is independently invented. > What users have to do is determined by the terms set forth in the > patent. E.g.: the QR-code patent has (I believe) not expired yet but > has always permitted using the idea without any explicit license under > the condition that all use is actually spec conformant. Generally patents, like copyright registrations, do not have "terms" for how you are allowed to use the patented technology. The patent just makes claims as to what is covered. For something completely new those claims often are pretty broad covering anything somebody could imagine the technology being used for. For something repurposed the claims tend to be narrow, as the inventor didn't actually come up with the original idea but claims the new application of it is novel in some way, and if you use it for anything else you're more likely to be free and clear. What you are talking about is a patent license, which is similar to a software license. You don't "copyright software under the GPL" - you just copyright the software full stop. Then, as a separate act, you issue however many licenses you wish to anybody you wish allowing them to do things that would otherwise infringe on the copyright. In the same way all a patent does is stake a claim on an idea, and then any licenses are a completely separate matter. If a patent holder wants to sue somebody they would point to what they're doing and then to the patent, and the court would determine if the action infringed, but the defense would be free to provide any license they believe they legitimately have from the patent holder that makes the action legal. > You seem to expect some due diligence from libtomcrypt authors before > having decided to publish their work and I don't find that reasonable. > I hope I've managed to explain why? So, I can't speak for libcrypt at all specifically, but I wouldn't assume that somebody has actually done due diligence before publishing anything. For all you know the authors of some random piece of software live someplace the patent is unenforceable and don't even care if it infringes, or they're protected by anonymity online. Back in the PGP ITAR days I believe somebody went through some loopholes to publish the software outside the US, and it is probably debatable whether that was legal under US law, but presumably the people who did it didn't care, and enforcement was unlikely at all, and especially unlikely if you didn't have plans to visit the US after bragging about distributing it. Really the same is true of software patents in general. For random individuals other than your own conscience it is pretty unlikely for there to be any kind of enforcement. For a business or concern of any size though it obviously is a risk that is probably not worth taking. This is arguably one of the value-adds a commercial distro could add: providing an assurance that anything in the distro is systematically and competently screened. Whether commercial distros actually due this in practice is something I don't know, though if they make promises and have the appearance of a decent program it might accomplish the CYA needs of due diligence for most companies... -- Rich
Re: [gentoo-dev] Guidance on distributed patented software
Joshua Kinard wrote: > > I'm not entirely sure what you'd like to ask the libtomcrypt authors. > > "We think there may be patents, but we don't know. Did you consider > > that?" > > No, actually, I was thinking something more along the lines of "Hey, are you > aware of these supposed patent claims about ECC/ECDSA implementations that > Red Hat says exist, and if so, did you do any research on them that you > could possibly share that led you to feeling confident to release your > implementation into the public domain". > > But I am open to better language. There's not neccessarily a conflict between a patented idea and a public domain implementation of that idea. Take a fictional example: You and I independently invent the same thing. You patent it, then write and publish an LGPL implementation. I, ignorant of your accomplishment, later write and publish a different implementation, placing it in the public domain. You having a patent doesn't neccessarily matter to me publishing my implementation. It can be problematic for *users*. They might violate your patent terms (or not; it depends on your terms in the patent) if they use *any* implementation without having licensed the right to use your patented idea from you. (Of course only until your patent expires.) What users have to do is determined by the terms set forth in the patent. E.g.: the QR-code patent has (I believe) not expired yet but has always permitted using the idea without any explicit license under the condition that all use is actually spec conformant. The license for a software isn't connected to patents unless it explicitly states so, like GPL-3 Section 11 or Apache-2.0 Section 3. Public domain has no license text, so can have no such language. :) You seem to expect some due diligence from libtomcrypt authors before having decided to publish their work and I don't find that reasonable. I hope I've managed to explain why? Kind regards //Peter
[gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it
Symlinking FILESDIR into the work tree has the unintended consequence
of preserving all original file metadata, including system-specific ACLs
and so on. When these files are installed, this could lead to
unintentionally copying this metadata to the system and/or binary
packages.
Let's copy all files instead and drop metadata in the process. Since
FILESDIR is expected to be small by design, this shouldn't cause any
major trouble. It is also easier and less likely to cause regressions
than making sure stuff is not preserved when installing.
Unfortunately, a similar problem applies to DISTDIR. However,
installing files from DISTDIR is rarer than from FILESDIR, so I guess
we'll cross that bridge when we get to it.
Bug: https://bugs.gentoo.org/814857
Signed-off-by: Michał Górny
---
bin/phase-functions.sh| 2 +-
.../package/ebuild/prepare_build_dirs.py | 19 +--
2 files changed, 10 insertions(+), 11 deletions(-)
Changed in v3:
- use optimized copyfile from Portage (supports reflinking)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index d3221993d..9a4c97b16 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -296,7 +296,7 @@ __dyn_clean() {
rm -rf "${PORTAGE_BUILDDIR}/build-info"
rm -rf "${WORKDIR}"
- rm -f "${PORTAGE_BUILDDIR}/files"
+ rm -rf "${PORTAGE_BUILDDIR}/files"
fi
if [ -f "${PORTAGE_BUILDDIR}/.unpacked" ]; then
diff --git a/lib/portage/package/ebuild/prepare_build_dirs.py
b/lib/portage/package/ebuild/prepare_build_dirs.py
index 659198905..2e2ef73f4 100644
--- a/lib/portage/package/ebuild/prepare_build_dirs.py
+++ b/lib/portage/package/ebuild/prepare_build_dirs.py
@@ -1,4 +1,4 @@
-# Copyright 2010-2020 Gentoo Authors
+# Copyright 2010-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
__all__ = ["prepare_build_dirs"]
@@ -27,6 +27,7 @@ from portage.util import (
normalize_path,
writemsg,
)
+from portage.util.file_copy import copyfile
from portage.util.install_mask import _raise_exc
@@ -478,16 +479,14 @@ def _ensure_log_subdirs(logdir, subdir):
def _prepare_fake_filesdir(settings):
real_filesdir = settings["O"] + "/files"
-symlink_path = settings["FILESDIR"]
+filesdir = settings["FILESDIR"]
+portage.util.ensure_dirs(filesdir, mode=0o755)
-try:
-link_target = os.readlink(symlink_path)
-except OSError:
-os.symlink(real_filesdir, symlink_path)
-else:
-if link_target != real_filesdir:
-os.unlink(symlink_path)
-os.symlink(real_filesdir, symlink_path)
+# Copy files from real directory to ebuild directory (without metadata).
+if os.path.isdir(real_filesdir):
+shutil.copytree(
+real_filesdir, filesdir, copy_function=copyfile, dirs_exist_ok=True
+)
def _prepare_fake_distdir(settings, alist):
--
2.33.0
[gentoo-portage-dev] [PATCH v2] Copy files/* into the work tree instead of symlinking it
Symlinking FILESDIR into the work tree has the unintended consequence
of preserving all original file metadata, including system-specific ACLs
and so on. When these files are installed, this could lead to
unintentionally copying this metadata to the system and/or binary
packages.
Let's copy all files instead and drop metadata in the process. Since
FILESDIR is expected to be small by design, this shouldn't cause any
major trouble. It is also easier and less likely to cause regressions
than making sure stuff is not preserved when installing.
Unfortunately, a similar problem applies to DISTDIR. However,
installing files from DISTDIR is rarer than from FILESDIR, so I guess
we'll cross that bridge when we get to it.
Bug: https://bugs.gentoo.org/814857
Signed-off-by: Michał Górny
---
bin/phase-functions.sh | 2 +-
lib/portage/package/ebuild/prepare_build_dirs.py | 16 +++-
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index d3221993d..9a4c97b16 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -296,7 +296,7 @@ __dyn_clean() {
rm -rf "${PORTAGE_BUILDDIR}/build-info"
rm -rf "${WORKDIR}"
- rm -f "${PORTAGE_BUILDDIR}/files"
+ rm -rf "${PORTAGE_BUILDDIR}/files"
fi
if [ -f "${PORTAGE_BUILDDIR}/.unpacked" ]; then
diff --git a/lib/portage/package/ebuild/prepare_build_dirs.py
b/lib/portage/package/ebuild/prepare_build_dirs.py
index 659198905..9d83bacad 100644
--- a/lib/portage/package/ebuild/prepare_build_dirs.py
+++ b/lib/portage/package/ebuild/prepare_build_dirs.py
@@ -478,16 +478,14 @@ def _ensure_log_subdirs(logdir, subdir):
def _prepare_fake_filesdir(settings):
real_filesdir = settings["O"] + "/files"
-symlink_path = settings["FILESDIR"]
+filesdir = settings["FILESDIR"]
+portage.util.ensure_dirs(filesdir, mode=0o755)
-try:
-link_target = os.readlink(symlink_path)
-except OSError:
-os.symlink(real_filesdir, symlink_path)
-else:
-if link_target != real_filesdir:
-os.unlink(symlink_path)
-os.symlink(real_filesdir, symlink_path)
+# Copy files from real directory to ebuild directory (without metadata).
+if os.path.isdir(real_filesdir):
+shutil.copytree(
+real_filesdir, filesdir, copy_function=shutil.copyfile,
dirs_exist_ok=True
+)
def _prepare_fake_distdir(settings, alist):
--
2.33.0
[gentoo-portage-dev] [PATCH] Copy files/* into the work tree instead of symlinking it
Symlinking FILESDIR into the work tree has the unintended consequence
of preserving all original file metadata, including system-specific ACLs
and so on. When these files are installed, this could lead to
unintentionally copying this metadata to the system and/or binary
packages.
Let's copy all files instead and drop metadata in the process. Since
FILESDIR is expected to be small by design, this shouldn't cause any
major trouble. It is also easier and less likely to cause regressions
than making sure stuff is not preserved when installing.
Unfortunately, a similar problem applies to DISTDIR. However,
installing files from DISTDIR is rarer than from FILESDIR, so I guess
we'll cross that bridge when we get to it.
Bug: https://bugs.gentoo.org/814857
Signed-off-by: Michał Górny
---
bin/phase-functions.sh | 2 +-
lib/portage/package/ebuild/prepare_build_dirs.py | 15 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index d3221993d..9a4c97b16 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -296,7 +296,7 @@ __dyn_clean() {
rm -rf "${PORTAGE_BUILDDIR}/build-info"
rm -rf "${WORKDIR}"
- rm -f "${PORTAGE_BUILDDIR}/files"
+ rm -rf "${PORTAGE_BUILDDIR}/files"
fi
if [ -f "${PORTAGE_BUILDDIR}/.unpacked" ]; then
diff --git a/lib/portage/package/ebuild/prepare_build_dirs.py
b/lib/portage/package/ebuild/prepare_build_dirs.py
index 659198905..0e85ded8b 100644
--- a/lib/portage/package/ebuild/prepare_build_dirs.py
+++ b/lib/portage/package/ebuild/prepare_build_dirs.py
@@ -478,16 +478,13 @@ def _ensure_log_subdirs(logdir, subdir):
def _prepare_fake_filesdir(settings):
real_filesdir = settings["O"] + "/files"
-symlink_path = settings["FILESDIR"]
+filesdir = settings["FILESDIR"]
+portage.util.ensure_dirs(filesdir, mode=0o755)
-try:
-link_target = os.readlink(symlink_path)
-except OSError:
-os.symlink(real_filesdir, symlink_path)
-else:
-if link_target != real_filesdir:
-os.unlink(symlink_path)
-os.symlink(real_filesdir, symlink_path)
+# Copy files from real directory to ebuild directory (without metadata).
+shutil.copytree(
+real_filesdir, filesdir, copy_function=shutil.copyfile,
dirs_exist_ok=True
+)
def _prepare_fake_distdir(settings, alist):
--
2.33.0
[gentoo-dev] Last-rites: media-libs/libyami
# A library without revdeps, EAPI-5. #776901 # Removal in ~30 days. OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Guidance on distributed patented software
On Mon, Sep 20, 2021 at 11:30 AM Ulrich Mueller wrote: > > > On Mon, 20 Sep 2021, Alec Warner wrote: > > > The devmanual discusses licensing as a core concept > > (https://devmanual.gentoo.org/general-concepts/licenses/index.html) > > but does not cover patents. My understanding is that we: > > > - set RESTRICT=bindist when we are unable to redistribute binaries > > (e.g. due to a license or patent restriction.) > > - set RESTRICT=mirror when we are unable to redistribute source code > > (e.g. due to a license of patent restriction.) > > IANAL, but IIUC patents only apply to programs that can run on a > computer. This is the case for binaries but not for source code. > > In other words, we don't need mirror restriction for source tarballs > because of patents. > > > - Sometimes, we remove patent encumbered source code from packages > > (e.g. with USE=bindist) so that we can build redistributable binaries > > with the patented features removed. > > We do, but normally this doesn't prevent us from distributing the source > code. Great, I'll send a patch to devmanual to add details about how we treat patented software in Gentoo (the original goal of the thread; I don't care what happens to openssl as much ;p) -A > > > 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?
