Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
On Mon, Aug 26, 2024 at 12:06:23PM +0200, Florian Weimer wrote: > * Peter Pentchev: > > > On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote: > >> * Lennart Poettering: > >> > You don't really have to live with such a limitation. In systemd we > >> > have code that works around this limitation via O_PATH. i.e. when > >> > connect()ing you first open the socket inode with O_PATH, and then you > >> > fire the connect() specifying /proc/self/fd/ as path. That always > >> > fits into the 108ch limit. > >> > >> Do you think this is useful more generally? What about opening files > >> with names longer than PATH_MAX? > >> > >> > bind()ing to an overly long unix socket path is also doable, but > >> > harder (since you cannot O_PATH on an inode that doesn't exist > >> > yet). The way I'd do it is via chdir() to the dir of the target path > >> > and binding to a relative path then. But chdir() is of course icky, > >> > since it's a global property of a process, hence will affect all > >> > threads. Hence, maybe do this in a short-lived forked off process. > >> > >> I would have expected that it's possible to use a directory descriptor > >> under /proc/self/fd as the base, but that doesn't seem to work for some > >> reason. > > > > I think the reason is O_PATH - bind(2) is not among the syscalls that > > it is documented to allow. However, see the attached program that > > creates a subdirectory with a long name in the current working > > directory, opens it without O_PATH, but with O_DIRECTORY, and then > > binds a Unix-domain socket to /proc/self/fd/N; it works for me at > > least on Debian testing and a month-or-two-old Fedora pre-42 Rawhide. > > Yes, that's what I meant with “as the base”. But my test program was > broken, and fixing it allowed me to creat the socket. > > *However*, if you do this, getsockname keeps returning > /proc/self/fd/3/meow even if descriptor 3 is closed. /proc/self/fd is > also visible across process boundaries. I wonder if the socket name is > actually /proc/self/fd/3/meow and not the alternate long name. But then > why does it show up in the file system at this point? Anyway, this > looks like it triggers some sort of kernel bug, so I really don't think > this can be recommended as an approach. Argh, I didn't even think about the "across process boundaries" aspect, and it is actually an important one - I think there is precedent for servers that have an out-of-band way to advertise to clients where the endpoints that they listen on are (at the very least there is varlink, but there surely are other ways, too). So, yeah, you are correct that this should not be recommended as a general approach, even with a list of caveats. Thanks! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
On Thu, Aug 22, 2024 at 10:09:56PM +0300, Peter Pentchev wrote:
> On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote:
> > * Lennart Poettering:
> >
> > > On Mi, 07.08.24 13:09, Vít Ondruch (vondr...@redhat.com) wrote:
> > >
> > >> With new RPM, I hit the limit in two packages:
> > >>
> > >> https://koschei.fedoraproject.org/package/rubygem-abrt
> > >>
> > >> https://koschei.fedoraproject.org/package/rubygem-pg
> > >>
> > >>
> > >> I have read:
> > >>
> > >> https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars
> > >>
> > >> https://stackoverflow.com/questions/34829600/why-is-the-maximal-path-length-allowed-for-unix-sockets-on-linux-108
> > >>
> > >>
> > >> But I still wonder why we should live with such limitation in 21st
> > >> century.
> > >
> > > You don't really have to live with such a limitation. In systemd we
> > > have code that works around this limitation via O_PATH. i.e. when
> > > connect()ing you first open the socket inode with O_PATH, and then you
> > > fire the connect() specifying /proc/self/fd/ as path. That always
> > > fits into the 108ch limit.
> >
> > Do you think this is useful more generally? What about opening files
> > with names longer than PATH_MAX?
> >
> > > bind()ing to an overly long unix socket path is also doable, but
> > > harder (since you cannot O_PATH on an inode that doesn't exist
> > > yet). The way I'd do it is via chdir() to the dir of the target path
> > > and binding to a relative path then. But chdir() is of course icky,
> > > since it's a global property of a process, hence will affect all
> > > threads. Hence, maybe do this in a short-lived forked off process.
> >
> > I would have expected that it's possible to use a directory descriptor
> > under /proc/self/fd as the base, but that doesn't seem to work for some
> > reason.
>
> I think the reason is O_PATH - bind(2) is not among the syscalls that
> it is documented to allow. However, see the attached program that
> creates a subdirectory with a long name in the current working
> directory, opens it without O_PATH, but with O_DIRECTORY, and then
> binds a Unix-domain socket to /proc/self/fd/N; it works for me at
> least on Debian testing and a month-or-two-old Fedora pre-42 Rawhide.
> ("Works for me" in the sense that "cd this-...; nc -v -U meow" says
> that it has connected to the Unix-domain socket; of course, the program
> does not attempt to communicate with connected clients)
...and of course I forgot to attach the program, did I not...
> > You could also use a long-lived service thread that has called
> > unshare(CLONE_FS), so that it has its own current directory. This is a
> > bit iffy because glibc won't know about it, but it's already used by
> > some popular file servers, so it should be okay. I've posted a patch
> > that implements a proper NPTL facility for this, but it met with a
> > surprising amount of resistance. I suppose I could dust it off and
> > repost it.
>
> That might actually work, yeah.
>
> G'luck,
> Peter
>
> --
> Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com
> PGP key:https://www.ringlet.net/roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
--
Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define DIRNAME "this-is-a-directory-with-a-really-long-name-and-stuff-and-such-and-stuff-and-such-and-stuff-and-such-and-stuff-and-such"
#define SLEEP_TIME 120
int main(void)
{
puts("Hell world");
printf("Trying to create a directory if it does not exist: %s\n", DIRNAME);
Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote:
> * Lennart Poettering:
>
> > On Mi, 07.08.24 13:09, Vít Ondruch (vondr...@redhat.com) wrote:
> >
> >> With new RPM, I hit the limit in two packages:
> >>
> >> https://koschei.fedoraproject.org/package/rubygem-abrt
> >>
> >> https://koschei.fedoraproject.org/package/rubygem-pg
> >>
> >>
> >> I have read:
> >>
> >> https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars
> >>
> >> https://stackoverflow.com/questions/34829600/why-is-the-maximal-path-length-allowed-for-unix-sockets-on-linux-108
> >>
> >>
> >> But I still wonder why we should live with such limitation in 21st century.
> >
> > You don't really have to live with such a limitation. In systemd we
> > have code that works around this limitation via O_PATH. i.e. when
> > connect()ing you first open the socket inode with O_PATH, and then you
> > fire the connect() specifying /proc/self/fd/ as path. That always
> > fits into the 108ch limit.
>
> Do you think this is useful more generally? What about opening files
> with names longer than PATH_MAX?
>
> > bind()ing to an overly long unix socket path is also doable, but
> > harder (since you cannot O_PATH on an inode that doesn't exist
> > yet). The way I'd do it is via chdir() to the dir of the target path
> > and binding to a relative path then. But chdir() is of course icky,
> > since it's a global property of a process, hence will affect all
> > threads. Hence, maybe do this in a short-lived forked off process.
>
> I would have expected that it's possible to use a directory descriptor
> under /proc/self/fd as the base, but that doesn't seem to work for some
> reason.
I think the reason is O_PATH - bind(2) is not among the syscalls that
it is documented to allow. However, see the attached program that
creates a subdirectory with a long name in the current working
directory, opens it without O_PATH, but with O_DIRECTORY, and then
binds a Unix-domain socket to /proc/self/fd/N; it works for me at
least on Debian testing and a month-or-two-old Fedora pre-42 Rawhide.
("Works for me" in the sense that "cd this-...; nc -v -U meow" says
that it has connected to the Unix-domain socket; of course, the program
does not attempt to communicate with connected clients)
> You could also use a long-lived service thread that has called
> unshare(CLONE_FS), so that it has its own current directory. This is a
> bit iffy because glibc won't know about it, but it's already used by
> some popular file servers, so it should be okay. I've posted a patch
> that implements a proper NPTL facility for this, but it met with a
> surprising amount of resistance. I suppose I could dust it off and
> repost it.
That might actually work, yeah.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: openssl engine-related FTBFS and Boost
On Fri, Jul 05, 2024 at 11:10:08AM +0100, Joe Orton wrote: > On Tue, Jul 02, 2024 at 02:05:38PM +0200, Dmitry Belyavskiy wrote: > > In the long-term it would be better to provide a patch fixing build of the > > package. Probably adding -DOPENSSL_NO_ENGINE to build flags will work. > > Engines are deprecated. You should not use engines and should migrate to > > providers. > > I really think this is silly. Looking at the Boost headers they already > conditionalize support for ENGINE *in the way that OpenSSL upstream > intended*. > https://www.boost.org/doc/libs/1_74_0/boost/asio/ssl/detail/openssl_types.hpp > > #if !defined(OPENSSL_NO_ENGINE) > # include > #endif // !defined(OPENSSL_NO_ENGINE) > > So, no, Boost should not be "fixed". should > simply "#define OPENSSL_NO_ENGINE" if you want Fedora packages to drop > ENGINE support. We have broken the way Fedora packages consume the > OpenSSL API - it should be reverted, we're just heaping unnecessary work > on other package maintainers. I wonder if it would be possible (of course it is technically possible, more like how hard it would be) to make the OpenSSL devel package conditionally define OPENSSL_NO_ENGINE if another package is not installed. I can think of at least two ways to do that: - alternatives (but maybe that's my Debian background talking) - #include_next games G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self-Introduction: Peter Pentchev
On Tue, May 28, 2024 at 09:35:52AM +0200, Dominik 'Rathann' Mierzejewski wrote: > Hello, Peter! > > On Tuesday, 28 May 2024 at 08:23, Peter Pentchev wrote: > [...] > > If my packager group application is accepted, > > Have you gone through the other steps outlined in > https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ > ? Yes, and I already have a reviewed package - spiped, https://bugzilla.redhat.com/show_bug.cgi?id=2265862 - and AFAIU the next step should be creating a dist-git repository, hence the packager group application :) > > I will try to > > help several packaging teams within Fedora (Python, Perl, Rust, maybe > > some other topic-based ones) and probably separately package some tools > > that I use on a daily basis, some written by me, some by others. > > Sounds good. Welcome to Fedora! Thank you! From what I've seen in the mailing lists in the past several years when I've been mostly lurking, it is mostly a nice place :) > > PGP key:http://people.FreeBSD.org/~roam/roam.key.asc > > You might want to update this URL to use https. Right... good catch. Of course, the FreeBSD webserver had an automatic redirect, but it was kind of high time I moved that over to my own website. Thanks! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Self-Introduction: Peter Pentchev
Hi, My name is Peter Pentchev. I am a software developer who has been wrangling computers since 1986 and free/libre-software OS's and distributions since 1997 (Slackware and RedHat (way before RHEL) at first, then a decade or two of FreeBSD, then a decade or two of Debian). I have maintained packages for FreeBSD since the year 2000, for Debian since 2004-2005, and (unofficially, in personal and vendor repositories) for CentOS and RHEL since 2013. My main interests lie in system and network programming, but I have dabbled in almost all areas of software development over the years with varying degrees of success. My longest programming experience is in C and Perl, but lately I prefer a mixture of Rust, type-checked Python, and, when absolutely necessary, very carefully written POSIX shell and Bash. If my packager group application is accepted, I will try to help several packaging teams within Fedora (Python, Perl, Rust, maybe some other topic-based ones) and probably separately package some tools that I use on a daily basis, some written by me, some by others. Thanks for reading this, and thanks for working on Fedora - it takes so many different kinds of people doing so many different kinds of tasks to create and maintain a working software distrubition! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Source-git SIG report #1 (June 2021)
On Fri, Jun 25, 2021 at 02:40:22PM +0200, Miroslav Suchý wrote: > Dne 24. 06. 21 v 23:22 Miro Hrončok napsal(a): > > AFAIK git does not grantee to produce byte2byte identical archives > > across different versions of git, zlib, gzip etc. So even if upstream > > signs the git generated archive, generating a byte2byte identical one > > might be tricky. > > Neither git nor tar can do that. But it is not impossible. E.g. Tito [1] has > some hacks on top of git-archive which produces identical tar-balls. > > [1] https://github.com/rpm-software-management/tito/ FWIW, pristine-tar (http://joeyh.name/code/pristine-tar/) can handle almost all upstream tarballs, and it also has support for storing detached signatures alongside its metadata. I keep hearing people say that there are cases when it fails, but it has worked for me for dozens of packages. Of course, it does have its own expectations about the structure of the Git repository, but those are mostly limited to "give me a branch to play in, I'll take care of the rest". G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On Thu, Sep 24, 2020 at 01:01:17PM -0400, Neal Gompa wrote: > On Thu, Sep 24, 2020 at 12:00 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization > > > > == Summary == > > Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did > > not get widespread and the tool is not much maintained it became > > burden to make existing debugging tools compatible with Fedora debug > > info. > > > > == Owner == > > * Name: [[User:jankratochvil| Jan Kratochvil ]] > > * Email: jan.kratoch...@redhat.com > > > > > > == Detailed Description == > > > > Debug info files *.debug contained in *-debuginfo.rpm are very big in > > general (x86_64 Fedora 32 distribution has debug/ directory of 82GB > > while all its other files are only 75GB). There exist several methods > > how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18 > > started using DWZ tool (from [[Features/DwarfCompressor]]) while > > [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html > > Google implemented] the same goal in a different way called > > -fdebug-types-section. > > > > Almost nobody uses existing Fedora DWZ (only Fedora/CentOS/RHEL and > > SuSE OSes) and so its support is missing in tools like > > [https://lldb.llvm.org/ LLDB], > > [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]] > > or binutils readelf. -fdebug-types-section is used internally by > > Google (produced by clang). Debian does not store any debug info > > archives. Ubuntu uses neither -fdebug-types-section nor DWZ. > > > > This is not true. Debian started producing -dbgsym packages and > putting them in a separate repository years ago: > https://wiki.debian.org/AutomaticDebugPackages > > dwz is used by virtually all RPM based distributions now, including > OpenMandriva (a clang-based distro). I know this because I implemented > it. :) > > I do not know whether Debian has started using dwz by default because > I haven't dug into how the -dbgsym package generation works in detail. Most of the packages that use recent versions of debhelper (the tool that automates many steps of the Debian packaging) have run dwz for the past couple of years. I do not have any statistics though. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: booting successfully with read-only file system
On Fri, Jul 03, 2020 at 01:32:12PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jul 03, 2020 at 09:18:42AM -0400, Colin Walters wrote: > > On Thu, Jul 2, 2020, at 11:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > It would be great if we could fairly reliably boot with a read-only > > > root file system, > > > > Eh, just mount a tmpfs for /var, and an overlayfs for /etc (backed by a > > tmpfs). > > I see that this thread is one massive communication failure on my part :( > > I wrote about "booting successfully with a read-only file system", but I > see that I didn't say "... when the disk cannot be mounted rw because of > file system errors". ...but Colin did not say that. Neither tmpfs nor overlayfs (backed by tmpfs) require any existing disk filesystems to be mounted read-write. TBH, that was my first thought when I read your original e-mail: "why would units fail if they only want to write non-persistent stuff to an area that may perfectly well be mounted as tmpfs, just as /run usually is?" > I thought it'd be clear from the context, but it's > clearly not. Anyway, while I'm a big fan of coreos and read-only-on-purpose, > I was writing about traditional systems in a read-only-by-accident scenario, > i.e. about the system behaving gracefully when the disk is ***unexpectedly*** > read-only. > > Zbyszek > > PS. OK, I know I wrote about making it read-only on purpose using a > kernel commandline option, so really we're just pretending it was > unexpected for testing purposes, but you get what I mean I hope. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: A few questions about a package update / policy questions / GCC 9 error
On Wed, Jun 10, 2020 at 02:22:53PM -0400, Simo Sorce wrote:
> On Wed, 2020-06-10 at 14:16 -0400, Simo Sorce wrote:
> > On Wed, 2020-06-10 at 20:01 +0200, Dan Čermák wrote:
> > > "Nathanael D. Noblet" writes:
> > >
> > > > Hello,
> > > >
> > > > I maintain beanstalkd which is a message server of sorts. It recently
> > > > released a new version however some changes I'm not 100% sure about.
> > > >
> > > > When compiling I got the following GCC error.
> > > >
> > > > usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
> > > > specified bound 201 equals destination size [-Werror=stringop-
> > > > truncation]
> > > > 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> > > > (__dest));
> > > > | ^~
> > > >
> > > >
> > > > Results via google says that strncpy needs to have the third argument
> > > > less than the 2nd, so I've got this patch, similar to others:
> > > >
> > > > --- beanstalkd-1.12/tube.c.org 2020-06-10 09:37:35.129224346 -0600
> > > > +++ beanstalkd-1.12/tube.c 2020-06-10 09:37:42.761138035 -0600
> > > > @@ -12,7 +12,7 @@
> > > > if (!t)
> > > > return NULL;
> > > >
> > > > -strncpy(t->name, name, MAX_TUBE_NAME_LEN);
> > > > +strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
> > > > if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
> > > > t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
> > > > twarnx("truncating tube name");
> > > >
> > > > You'll notice it was already checking the len-1 for null. Can anyone
> > > > verify that my change won't cause some un-intended bug I don't
> > > > understand?
> > >
> > > If I understand it correctly, then you are now invoking undefined
> > > behavior: you copy at most MAX_TUBE_NAME_LEN-1 bytes to t->name and then
> > > check whether the following byte (that was never written to) is not
> > > equal to 0. I have not checked the code of beanstalkd, but the contents
> > > of t->name[MAX_TUBE_NAME_LEN - 1] will be zero if it was allocated via
> > > calloc() at best or random at worst. Irrespectively of that, the check
> > > now no longer does what it *should*: null terminate the string if it is
> > > not null terminated. It will now randomly null terminate it or not at
> > > all.
> >
> > strncpy() is a truly awful API unfortunately, the change is
> > meaningless, but it is not random as Dan says.
> >
> > The original form is more correct though, because now you can get
> > spurious warnings that the string have been truncated when that is not
> > true. (If t->name is not zeroized you will get the spurious warning for
> > any string shorter than MAX_TUBE_NAME_LEN, which is the opposite of
> > what the warning says.
> >
> > The third argument to strncpy can be as long as the size of the buffer
> > you are writing into, the additional check you have there insures that
> > the string is terminated (even if that requires truncation).
> >
> > So I would say you should drop your change and stop believing in random
> > google results :)
>
> Sorry, hit send prematurely.
>
> If you really want to avoid the warning instead of ignoring it, you
> should change the code this way:
>
> strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
> if (t->name[MAX_TUBE_NAME_LEN - 2] != '\0') {
> t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
> twarnx("truncating tube name");
> }
>
> NOTE: the -2 in the condition, this is needed because memory locations
> start counting from 0, so if you write N-1 bytes the Nth-1 byte is at
> the N-2 position when you start counting from 0.
> And that is the last position your strncpy wrote to, and if that is not
> 0 then potentially string truncation occurred.
>
> You still want to zero the last available byte in that case and not the
> N-1 available byte, so you set N-1 to 0, not N-2.
>
> N-1 is the Nth byte when you start counting from 0 and N is the size of
> the array.
...or use snprintf() and check! its! return! value! (sorry, I've had to
explain that to too many people over too many years).
Something like (completely, totally untested, but should give you an
idea):
const int re
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Tue, Jun 02, 2020 at 07:47:12PM -0700, John M. Harris Jr wrote:
> On Tuesday, June 2, 2020 2:05:01 AM MST Joe Orton wrote:
> > On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
> > >
> > > > == Detailed Description ==
> > > > By default php-fpm is used for a few versions. mod_php is not
> > > > supported for threaded modules. mod_php usage also increases security
> > > > risk, sharing the same process than httpd.
> > > >
> > > > Drop mod_php from php build. This will only affect user of httpd in
> > > > "prefork" mode, which will also use php-fpm.
> > > >
> > > > php-fpm is already used but most users of httpd and nginx without any
> > > > issue.
> >
> > >
> > > Based on the replies downthread, it seems that some people are still
> > > using it and want to keep it...
> >
> >
> > If the existence of non-zero user demand blocked removal of defunct
> > technology in Fedora I guess we'd still be shipping SysV init.
> >
> > We made the switch from forked-httpd + mod_php to threaded-httpd +
> > php-fpm by default in Fedora 27, so we've spread this transition over
> > six full release cycles. We've had AFAIK *zero* bug reports about
> > making the default switch.
> >
> >
> > > Is mod_php a maintainance burder and/or a noticable installation
> > > overhead when not used? And if it is, would additional help with the
> > > maintainance that was offered make it easier to keep?
> >
> >
> > I'm not seeing any technical argument in this thread to support keeping
> > mod_php. If there were, that would be interesting, but otherwise I
> > think the package owner should be trusted and empowered to make this
> > change.
> >
> > Regards, Joe
>
> If it's dropped, it wouldn't really be possible for me to make a mod_php
> package to replace it due to the integration, so I can't really see a way of
> keeping a compat package if it's removed, and keeping it around doesn't break
> anything.
Do you have an application that absolutely cannot work using php-fpm, or
is it a matter of "must set some time aside to migrate and test
everything after a switch from mod_php to fpm"?
If it's the first, people have repeatedly stated that they want to know
what it is and why. Also, people have repeatedly stated that mod_php is
strongly recommended against by upstream. Also, people have repeatedly
stated that having to support mod_php blocks future work.
If it is the second, unfortunately that is true of many changes.
Sometimes we have to do some work to adapt to a new, better way of doing
things. Sometimes we can see at once that the new way is indeed better;
sometimes it takes us months or even years to realize that. And yes,
there may be particular circumstances when the benefits of the new way
do not really outweigh the benefits that the old way provided, but it is
not easy for me to imagine a situation when a switch from mod_php to
php-fpm would break things. Yes, I can, yes, I know that one can install
more modules, make some PHP applications use shared server memory and
whatnot; still, it seems to me that ultimately there are better ways to
handle most of these.
The vast, overwhelming majority of installations do not *need* mod_php.
The vast, overwhelming majority of installations would *benefit* from
a switch to php-fpm.
The vast, overwhelming majority of installations *currently* using
mod_php are doing it because of conventional wisdom ("this is the way to
set up a PHP site") that is rooted in the times when php-fpm
*did not exist* - so it's much more of "this was the only possible way
to set up a PHP site back then" than "this is the best way to set up
a PHP site now".
Yep, migration needs work. Acknowledged. The same could be said of
changing an init system, changing a default syslog implementation,
changing the way a database server is configured, changing the defaults
for a proxy server's configuration... and so many more.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On Fri, May 22, 2020 at 10:08:04AM +0100, Tomasz Kłoczko wrote: > On Fri, 22 May 2020 at 02:17, Miro Hrončok wrote: > > > Hello, in order to deliver Python 3.9, we are running a coordinated > > rebuild in a > > side tag. > > > > https://fedoraproject.org/wiki/Changes/Python3.9 > > > [..] > > I'm only curious why to make transition to python 3.9 was > chosen "debianised way"? (yes, I am aware of the slight irony of me replying to this message with my current e-mail signature :)) > Originally was python package. Than was python python2 and python3. Now it > is python3.9. > Why not is used still and just python and to provide necessary dependencies > during transition python3.8? > That way as well is casing that with each python major version upgrade all > macros needs to be multiplied. Are you asking why python3.8 and python3.9 are separate packages? If so, I think that previous messages to this list mentioned that many people need to have more than one Python interpreter installed. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Tue, Dec 17, 2019 at 01:04:43PM +0100, Kevin Kofler wrote:
> Neal Gompa wrote:
> > You've been saying this a lot lately, and this isn't actually backed
> > up by reality.
> >
> > Debian *is* dropping Python 2 support.
>
> It was Adam Williamson who claimed that Debian would still support Python 2.
> I neglected to verify that claim, sorry for that.
>
> But this means that his argument that users who need Python 2 should just
> switch to Debian is null and void.
>
> So far, Fedora has always been one of the few distributions willing to ship
> legacy compatibility libraries to keep software working. See GTK+ 1, Qt 3,
> etc. (Some of it, such as Qt 3, was partly my own work, some of it, such as
> GTK+ 1, has been entirely done by other volunteers.) With the Python 2
> policy, and also with the package deprecation process that was introduced
> recently, Fedora is making a radical U-turn, which will make it much less
> useful for end users. And there is no real alternative to switch to. Debian
> is clearly not one.
>
> Maintainers need to realize that there is lots of niche software out there
> that is effectively unmaintained (and thus will never get ported to Python 3
> etc.), but that works, fulfills some task, and has no more recent
> alternative available. What should people relying on such software do?
Either figure out a way to get people to maintain the software, or
figure out a way to get people to develop a replacement, or keep using
the unmaintained software on equally unmaintained older versions of
operating systems that it will run on.
Sorry for the bluntness, but, well...
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Mon, Dec 16, 2019 at 09:54:49PM -0500, Neal Gompa wrote: > On Mon, Dec 16, 2019 at 9:37 PM Kevin Kofler wrote: > > > > Adam Williamson wrote: > > > BTW, there is another point here which you may not appreciate: Fedora > > > and Debian aren't really in competition. Fedora does not see its job as > > > being to Conquer The World and have everyone run Fedora. Fedora is > > > targeted at particular purposes and particular audiences. If a given > > > feature isn't actually driving Fedora's mission forward in any way, > > > it's reasonable to consider not having it any more, or at least not > > > making it a core part of the distribution and subject to blocking > > > requirements and so on. There comes a point at which we don't need to > > > support Python 2 for the people and use cases at which Fedora is aimed. > > > Will there still be people who need Python 2 for *something* at this > > > point? Probably! But, just as you point out, if so, they can get it > > > somewhere else. > > > > > > Someone using Debian instead of Fedora because they need Python 2 isn't > > > necessarily a *problem* for Fedora. It's only a problem if it would've > > > served Fedora's goals and purposes for that person to be using Fedora. > > > If what they do isn't really a part of Fedora's goals...why should we > > > worry about them using Debian? Debian is a fine distribution. Nothing > > > wrong with it. > > > > > > To put it another way...Debian and Fedora have different purposes and > > > different goals. Us dropping Python 2 earlier than Debian do is *things > > > working the right way*. We (arguably) do more than Debian to drive the > > > adoption and stabilization of new technologies - new stuff tends to > > > show up in Fedora earlier than it shows up in Debian. Debian (arguably) > > > does more than we do to provide long-term support for older software > > > and support for alternate architectures. This is a *good* thing. It's > > > an ecosystem that helps everyone. > > > > Except that this argument does not match actual facts. Debian is actually > > pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3 > > several years ago and has already started the process of dropping Qt 4. We > > still support these and even kdelibs 3 and 4 in Fedora (mostly because I am > > keeping these alive – it turns out that this is actually very little work: > > no new upstream releases to care about, just occasionally an FTBFS fix or a > > security fix to backport). > > > > The fact that even Debian is not trying to kick out Python 2 yet shows that > > it is way too early to even consider it. Fedora is the only distribution > > insane enough to do such a radical move with draconian enforcement, even > > over the heads of the maintainers of packages depending on Python 2. (We now > > need explicit permission to depend on a package, a completely unprecedented > > and ridiculous move.) > > > > You've been saying this a lot lately, and this isn't actually backed > up by reality. > > Debian *is* dropping Python 2 support. As of right now, they are > working on transitioning to making providing Python 2 packages as > a bug of serious severity. This means that packages in unstable providing > Python 2 modules will no longer automatically transition to testing > and need exceptions to do so. In addition, there's discussion underway > to make it rc-blocking as well, meaning that packages may not be able > to transition into testing *without* removing Python 2 support > *first*. > > While not all of this is implemented just yet in Debian (everything > moves glacially slow there...), it *is* happening. Debian definitely > does not want to make another release with Python 2 in the > distribution. Ubuntu has already decided to filter out all Python 2 > packages from Ubuntu 20.04 LTS, so it's not going to be there either. > > And you know what? This was all made possible by Fedora's work over > the last several releases to port lots of software to Python 3, > aggressively migrate to Python 3 by default, and now finally dropping > Python 2 stuff over the last three releases. > > We may keep the python27 interpreter package for a while, but I don't > expect us to keep much beyond that. Right. Must learn to read before posting. Must learn to read the whole thread before posting. As a (relatively recent) Debian Developer, I have to say I agree with everything that Neal said, including the parts about Fedora
Debian and Python 2 [Was: Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion]
On Mon, Dec 16, 2019 at 05:30:14PM -0800, Adam Williamson wrote:
> On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
[snip]
> > This doesn't change the fact that many Python scripts *cannot run on Python
> > 3*. Debian is not a museum piece either, and yet they don't just kill the
> > old
> > version. The two versions can, and do, work when both installed in
> > parallel.
>
> We are, uh, aware of this. They have been installed in parallel on most
> Fedora installs for like a decade now.
>
> BTW, there is another point here which you may not appreciate: Fedora
> and Debian aren't really in competition. Fedora does not see its job as
> being to Conquer The World and have everyone run Fedora. Fedora is
> targeted at particular purposes and particular audiences. If a given
> feature isn't actually driving Fedora's mission forward in any way,
> it's reasonable to consider not having it any more, or at least not
> making it a core part of the distribution and subject to blocking
> requirements and so on. There comes a point at which we don't need to
> support Python 2 for the people and use cases at which Fedora is aimed.
> Will there still be people who need Python 2 for *something* at this
> point? Probably! But, just as you point out, if so, they can get it
> somewhere else.
>
> Someone using Debian instead of Fedora because they need Python 2 isn't
> necessarily a *problem* for Fedora. It's only a problem if it would've
> served Fedora's goals and purposes for that person to be using Fedora.
> If what they do isn't really a part of Fedora's goals...why should we
> worry about them using Debian? Debian is a fine distribution. Nothing
> wrong with it.
>
> To put it another way...Debian and Fedora have different purposes and
> different goals. Us dropping Python 2 earlier than Debian do is *things
> working the right way*. We (arguably) do more than Debian to drive the
> adoption and stabilization of new technologies - new stuff tends to
> show up in Fedora earlier than it shows up in Debian. Debian (arguably)
> does more than we do to provide long-term support for older software
> and support for alternate architectures. This is a *good* thing. It's
> an ecosystem that helps everyone.
Also, well, Debian *is* dropping Python 2 in its next release:
- https://lists.debian.org/debian-python/2019/07/msg00080.html
- https://wiki.debian.org/Python/2Removal
Many Python 2 modules have been dropped already, many others will be
dropped in the coming months. Yes, there are complications such as
Calibre, but this is, for all intents and purposes, practically
a release goal now.
Sorry for contributing to the more-and-more-off-topic rant, but I just
felt the need to point this out, since I've seen it mentioned a couple
of times recently.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Fri, Oct 04, 2019 at 10:57:39AM -0400, Stephen Gallagher wrote:
[snip]
> * The state `dep_enabled` would be set whenever a stream becomes
> enabled because some other module stream depended on it. This state
> must be entered only if the previous state was `default` or
> `available`. (We don't want `enabled` or `disabled` streams being able
> to transition to this state.)
>
> * The state `default_enabled` would be set whenever a stream becomes
> enabled because a transaction pulled in a package from a default
> stream, causing it to be enabled. This state must only be entered if
> the previous state was `default` or `dep_enabled`. We don't want
> `enabled` or `disabled` to be able to transition to `default_enabled`.
> If a user requests installation of a package provided by a stream
> currently in the `dep_enabled` state, that stream should transition to
> the `default_enabled` state (meaning that now the user would expect it
> to be treated the same as any other default-enabled stream).
>
> * When running `dnf update`, if a module stream's dependency on
> another module changes to another stream, the transaction should cause
> that new stream to be enabled (replacing the current stream) if it is
> in the `dep_enabled` state.
> When running `dnf update` or `dnf system-upgrade`, if the default
> stream for a module installed on the system changes and the module's
> current state is `default_enabled`, then the transaction should cause
> the new default stream to be enabled.
Hmmm, maybe I'm not thinking straight today, but what happens when you
cross the streams? Correct me if I'm wrong in the following scenario:
Release N:
- foo: available streams: 1.0, 2.0, default: 2.0
- bar: depends on foo 1.0
- user installs foo and bar, gets bar and both foo 1.0
(default_enabled) and foo 2.0 (dep_enabled)
Release N + 1: (cross the streams)
- bar: depends on foo 2.0 now
- foo 1.0 gets uninstalled(?), foo 2.0... what happens to foo 2.0?
does it move to default_enabled or does it remain in dep_enabled?
or does it move to "enabled"?
Release N + 2: (the streams diverge again)
- foo: 1.0 is removed, 3.0 appears and is made default
- what happens on the user's machine? foo 2.0 needs to remain
installed, since bar explicitly depends on it, but will there also
be a foo 3.0 module installed (since the user requested the default
way back when, still in release N)?
Of course, it is completely possible that this case is indeed handled in
the proposal and I am the one at fault for not parsing it properly.
Anyway, thanks to you all for your work on this!
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Minimization Objective report
On Mon, Sep 30, 2019 at 02:58:54PM -0400, Matthew Miller wrote:
> On Mon, Sep 30, 2019 at 01:16:52PM -, Petr Pisar wrote:
> > > Is this a perfectly drop-in compatible replacement from a user point of
> > > view?
> > The user that executes "grep -P"? Not many changes. Usually a corner
> > cases that have a different performance or exhibit bug fixes.
>
> Yeah, that's the user I'm concerned with in this case, since _we're_ the one
> switching the library. I'm imagining users with scripts written by a
> sysadmin or grad student fifteen years ago which happen to use `grep -P`
> suddenly and mysteriously doing the wrong thing.
Eh, seeing as the grep(1) manual page itself still declares the option
as experimental, I think people using it *should* be aware of the
possibility of slight changes in behavior.
G'luck,
PEter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Tue, Sep 10, 2019 at 11:28:13PM -, vvs vvs wrote:
> But that's actually the same that I was trying to say. Meeting that
> activity statistics is the essence of such formal group. But grass-roots
> enthusiasts don't have such commitments. They can do some work
> occasionally if time allows but there is no strict agenda. This
> contradicts those expectations which you describe. So while there are
> people ready to do some work sometimes they just don't meet those
> criteria and this is not enough to be able to call them SIG.
Hopefully for the last time: the mailing list is not a requirement.
People checked the mailing list *after* the bugs were not fixed.
Fixing the bugs is the requirement.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to predict Python 3 SOABI naming scheme?!?
On Mon, May 20, 2019 at 07:58:09AM -0500, Richard Shaw wrote:
> I'm trying to get FreeCAD back in shape on Fedora[1] and what I hope is the
> last problem is that it's still building against the Python2 library
> (because it's default). I can override the behavior by specifying
> "-DPYTHON_SUFFIX= but it's different for every arch...
>
> $ python3
> Python 3.7.3 (default, Mar 27 2019, 13:41:07)
> [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sysconfig
> >>> sysconfig.get_config_var('SOABI')
> 'cpython-37m-x86_64-linux-gnu'
>
> I cobbled this together for the spec file but it may need work:
>
> %define py_suffix %(%{__python3} -c 'import sysconfig;
> sysconfig.get_config_var("SOABI")')
Erm, I think you'd get better results with a "print" thrown in there;
the interactive REPL interpreter shows you the value, but if you run
this through python3 -c, it will not actually output it to the standard
output unless you tell it to. Maybe try:
... -c 'import sysconfig; print(sysconfig.get_config_var("SOABI"))'
> The weird part is that it's evaluating as blank on Fedora 29 and 30[2]...
This much I'd expect, try with the print() in there.
> ...and working in Rawhide EXCEPT for armv7hl in which it's evaluating to[3]:
>
> -DPYTHON_SUFFIX=.cpython-37m-armv7hl-linux-gnu
I... honestly don't understand how this can happen. I don't understand
why python3 -c 'sysconfig.get_config_var()' would output anything...
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F29 System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation
On Mon, Jun 18, 2018 at 09:28:04AM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Build non-RELRO ELF binaries with
> .plt.got isolation =
> https://fedoraproject.org/wiki/Changes/.plt.got_Isolation
>
>
> Owner(s):
> * Florian Weimer
>
>
> Fedora 23 enabled hardening for all packages. However, some ELF
> binaries still use lazy binding. This change proposes additional
> hardening for them.
Hi,
First of all, thanks a lot for all your work! I apologize in advance,
since I'd not even heard of memory protection keys until reading this
today, so my question below is probably quite stupid.
> == Detailed description ==
> With the RELRO and BIND_NOW dynamic linker features, it is possible to
> make the array of function pointers which is used to implement dynamic
> linking (the GOT) read-only at run time. This makes it harder for
> exploit writers to overwrite these function pointers and redirect
> execution.
> However, some ELF binaries are still built and linked without these
> hardening features. Sometimes, this is due to package maintainer
> preferences. Sometimes, there are technical reasons which preclude the
> use of BIND_NOW because the way the application is written, it relies
> on lazy binding.
> This change proposes to link ELF binaries in such a way that the
> .plt.got section is loaded as a separated page at run
> time. As a result, it is possible to use a kernel feature called
> [http://man7.org/linux/man-pages/man7/pkeys.7.html memory protection
> keys] to make the GOT with its function pointer array read-only most
> of the time.
A sentence in this page jumped out at me - the one about the WRPKRU
instruction being completely unprivileged and so memory protection
keys not being very useful if the attacker may execute arbitrary
instructions. So I thought "well maybe they have in mind something
like allocate a key, make the page read-only, then trash the key and
start executing the program", but then...
> When the dynamic linker needs to perform a function
> symbol binding, it can make the GOT temporarily writable, for the
> current thread only.
...this came along. So what is supposed to stop an attacker who can
inject arbitrary code into the program from modifying the keys?
Or is this supposed to stop buffer-overflow exploits that overwrite
the GOT and thus cause the attacker's code to be executed later?
If so, then I apologize again, since it seems that this may be
sufficient to prevent that type of attack indeed.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RXKTYQKBHLQ66QVAHBNWI3CEGZKSQ7ZB/
