Re: systemd 252 feature: SUPPORT_END in /etc/os-release
Matthew Miller writes: > See: > https://lists.freedesktop.org/archives/systemd-devel/2022-October/048519.html > >Systemd will set the taint flag 'support-ended' if it detects that >the OS image is past its end-of-support date. This date is declared >in a new /etc/os-release field SUPPORT_END= described below. > >[...] > >os-release gained a new field SUPPORT_END=-MM-DD to inform the user >when their system will become unsupported. > > > Should we set this? I kind of think we should. Yes! We have started to set it in Amazon Linux 2022, and likely will at some point do so in prior versions as well (even though they all use older than 252 versions of systemd). This is very much so we can get as much information as possible into machine readable formats for security tooling to be able to read. > I would suggest we set it to the expected EOL based on the nominal schedule. > We could either release updates to extend it if we slip... or... just not do > that. The update is a rather small and unobtrusive one, and in our experience of doing updates to our system-release package (equivalent of fedora-release), we've managed to not cause any negative customer issues with modifications to it that weren't functional in some way (e.g. switching default repository setup to https endpoints rather than http) ___ 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: Help packaging a "C" library written in Rust
Fabio Valentini writes: > On Wed, Sep 7, 2022 at 10:53 PM Stewart Smith via devel > wrote: >> >> For Amazon Linux, we take a different approach to Fedora (but similar to >> RHEL) for software written in Rust and Go, and instead bundle >> dependencies rather than have each module/crate in its own RPM. We do it >> so we don't have to synchronize moving dependencies, or making these >> libraries/packages part of what customers could take a dependency on. > > Is this really a concern? Because of the way Rust packages are built, > they are essentially useless for any other purpose than serving as > dependencies for other Rust package builds. And because they are only > ever installed in temporary build environments (i.e. mock chroots), we > don't need to care about either the Updates policy (approved exception > by FESCo) and upgrade path (nobody should install those packages on > non-ephemeral systems). For Fedora? Probably not. If Crate Foo goes EoL (or any particular version of it does), Fedora can easily drop/bump the package pretty quickly. Possibly more relevant for EPEL though? Or may be more relevant there as there are more Rust and Go packages coming into the dependency graph. For Amazon Linux? Yes, it's a concern we have. Mostly because of our longer support life cycle for the OS and thus keeping the package set more constant. Plus, no matter how much we say "don't depend on this", somebody is going to, or we're not quite going to be able to wrangle all the teams supporting the random packages that would include these dependencies to move at roughly the same pace. It may also be relevant for 3rd party repositories, especially if also building for non-Fedora distros where the build dependencies just aren't otherwise available. >> Somewhere on my TODO list (or a TODO to delegate to someone) is to do >> that automatically from some packaging helper macros, but currently >> it's just way too manual and annoying. >> >> It'd be interesting to know what the general Fedora feeling is about >> having a distro/package level choice on this and a bunch of >> macros/scripts that help with that for packagers. > > The choice is basically already there, there's just no standardized > tooling for the "bad case". "bad case" is very much dependent on context :) . For Fedora, that's bundling, but for Amazon Linux, we at least currently view it the other way around, and that the bad case would be to import all the Go modules and Rust crates as packages and ship them. > For packages where not using the bundled dependencies is not possible, > it is already allowed to do so. > Having better (and consistent) tooling support for this case would be > great, though, and if somebody can contribute that, even better. Agree. It's probably something we (the Amazon Linux team) could/should contribute to, seeing as it is something that's way more relevant to us than Fedora itself. > But for packages where it *is* reasonably possible to build without > vendored dependencies, they also MUST NOT be built that way. This is > not a rule that's specific to Rust (or Go), but is a general rule for > Fedora packages. This is somewhere where the packaging guidelines for Fedora differs from downstream distros such as Amazon Linux (and I believe also RHEL/CentOS). > In this case, providing better tooling for building with vendored > dependencies would make it easier for packagers to be "lazy" and not > do "the right thing" rather than follow our rules, which is one of the > reasons why tooling isn't there yet ... While true for packages in Fedora, for packages outside Fedora, it may be worthwhile to have a solid opinion on tooling on a "good" way to do this. ___ 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: Help packaging a "C" library written in Rust
"Richard W.M. Jones" writes:
> On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote:
>>
>> https://gitlab.com/libblkio/libblkio
>>
>> This is a library that offers a C API. It happens to be implemented
>> in Rust, but it's not a "Crate" or anything like that.
>>
>> I wrote a spec file for it assuming it's a C library and it works fine
>> when building locally:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2124697
>>
>> However it turns out that it downloads stuff during the build and
>> therefore won't build in Koji. Apart from reading the Rust packaging
>> guidelines which don't seem applicable here (as this is not a Rust
>> Crate), that's as far as I've got on this one.
>>
>> Has anyone packaged anything like this for Fedora?
>
> It was pointed out on the bug that librsvg2 is in a similar situation.
> The answer there was to bundle ("vendor") all the Rust dependencies
> into the tarball. The command "cargo vendor" does this.
>
> For librsvg2 that's 278MB of dependencies (10 times larger than the
> sources of librsvg2 itself) in 265 separate Rust libraries. For
> libblkio it's 123MB of dependencies in a mere 21 libraries.
>
> Also there's no Provides: bundled(...) in the librsvg2 package.
For Amazon Linux, we take a different approach to Fedora (but similar to
RHEL) for software written in Rust and Go, and instead bundle
dependencies rather than have each module/crate in its own RPM. We do it
so we don't have to synchronize moving dependencies, or making these
libraries/packages part of what customers could take a dependency on.
Somewhere on my TODO list (or a TODO to delegate to someone) is to do
that automatically from some packaging helper macros, but currently
it's just way too manual and annoying.
It'd be interesting to know what the general Fedora feeling is about
having a distro/package level choice on this and a bunch of
macros/scripts that help with that for packagers.
___
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: Retiring the pcre package from Fedora
Lukas Javorsky writes: > Hi, > > As from the pcre-8.45, the upstream stopped supporting this > library. The recommended procedure is to switch onto the new pcre2 > library that has full upstream support. [1] I was looking into doing this as much as possible for AL2022 and managed to dig a bit on how to solve some of these. Some knowledge I gained (and pull requests linked) below: > As a result of this announcement, the older PCRE library in Fedora will be > retired. > Without upstream support, we don't have enough capacity to keep up > with the security and bugs-related issues, and thus we will support > only the new PCRE2 library. [2] > > The retirement procedure will happen in the upcoming weeks, so if you would > like to take over the package let us know. > > > The list of affected packages: > aide aide has been ported upstream (at least in the dev branch), https://src.fedoraproject.org/rpms/aide/pull-request/3 > cppcheck > cppcheck-gui cppcheck can be built without HAVE_RULES which will avoid pcre at the expense of functionality. > ganglia > ganglia-gmond Ganglia has been effectively dead upstream for a long time, with no functional security patching or keeping up to date with modern PHP. Arguably it should also go, or come with bright flashing warning lights. > grep There's been some development upstream on it: commit e0d39a9133e1507345d73ac5aff85f037f39aa54 Author: Carlo Marcelo Arenas Belón Date: Fri Nov 12 16:45:04 2021 -0800 grep: migrate to pcre2 and there's been a few bug fixes since then. It looks like a new release is in the works, so this should be solved shortly. > mod_security > mod_security-mlogc https://www.modsecurity.org/ seems to indicate that upstream has made some fundamental changes, and will now be community maintained. It does seem that PCRE2 support came in though https://github.com/SpiderLabs/ModSecurity/commit/f84614fe066f74d111b802d582599655d0d7e3af > nmap There appears to be a renewed interest upstream for porting over https://github.com/nmap/nmap/issues/1335 > openscap > openscap-engine-sce There's an upstream issue tracking this, I've mentioned that both Fedora and Amazon Linux are looking to be without pcre in the not too distant future. See https://github.com/OpenSCAP/openscap/issues/1873 > postfix-pcre Looks like it's a simple fix to the current upstream release: https://src.fedoraproject.org/rpms/postfix/pull-request/6 > zsh I haven't been able to find any clues on if upstream is working on this or not. I'd love to know though! ___ 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: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Ben Beasley writes:
> I support deprecating openssl1.1. We definitely shouldn’t be adding any
> new packages that depend on it.
>
> However, dropping the -devel package is almost as drastic as simply
> retiring the OpenSSL 1.1 package altogether. Grepping spec files for
> 'BuildRequires:.*openssl1' turns up the following packages that would
> immediately FTBFS:
>
> - anope
> - baresip
> - botan2
> - ceph
> - chatty
> - dotnet3.1
> - dsniff
> - eggdrop
> - erlang
> - kf5-kdelibs4support
> - libasr
> - libqxt-qt5
> - libre
> - libretls
> - lua-sec
> - nginx
The openssl11-devel BuildRequires in ngnix is in a conditional and has
been building with OpenSSL 3 for a while.
%if 0%{?fedora} || 0%{?rhel} >= 8
BuildRequires: openssl-devel
%else
BuildRequires: openssl11-devel
%endif
> - nodejs
Similarly for nodejs, openssl11 is conditional on building for RHEL.
___
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: proposal idea: EOL notifications
Adam Williamson writes: > On Thu, 2022-07-07 at 10:49 -0700, Stewart Smith via devel wrote: >> We actually have a skeleton design for such a thing (it says what >> updates and upgrades are available), but we've lagged on >> both posting to devel@ that it's something we've been working on, and I >> need to go and poke the person who needs to click the "publish this repo >> to github" button for the DNF plugin. I'll go do that now, as it would >> certainly add to this conversation. > > The problem with this is that it's a very fuzzy, messy space that's > hard to put limits and requirements on. > > The URL you mentioned is a case in point. That has more or less assumed > the status of running joke among a small group of people who care about > it. When you go to that URL, what you're getting now is a static JSON > document that is hand-maintained in the fedora ansible tree: > > https://pagure.io/fedora-infra/ansible/blob/main/f/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json > > when a release is branched, released, or EOLed, somebody from releng > has to remember to edit that file, and get the edit right. These days > that...usually...happens. I cannot possibly imagine a process which relies on good intentions ever failing :) > Way back in the mists of time, what you got at that URL was a view on > the release database of the pkgdb app, but that app hasn't existed for, > uh, quite a lot of years now. When it was decommissioned, we discovered > several things were relying on that API endpoint, which we replaced > with a static JSON file just until it could be replaced with something > less dumb. Yup, still here. > > The original planned replacement, IIRC, was PDC, which has now had an > entire lifecycle (conceived, created, deployed, given up on, and nearly > retired) without ever fully implementing all the release lifecycle > tracking bits that various pkgdb consumers wanted. (It's been a while, > but IIRC, there were issues with distinguishing between 'EOL', 'current > stable', 'branched' and 'rawhide' releases from PDC data). > > There are various sources of some kind of truth regarding the Fedora > release cycle. Bodhi has one - you can query > https://bodhi.fedoraproject.org/releases/ with content-type JSON and > you'll get some JSON back with some properties of various things Bodhi > considers to be "releases", including a "state". I've been converging on the thought that the same source of truth needs to be the input to the big things on the web site and docs, and well integrated into a regular release process that's as automated as humanly possible. By release, I mean "released any kind of package update" - i.e. the thing you do *all the time*. There's still the problem of people remembering to update it, but with fewer places to change it, at least it's easier to get them all. > I maintain one which is used by my 'fedfind' tool/library that various > bits of infra (mostly QA things, but also a few others) use. It is a > *different* hand-edited bit of JSON, which I created after being > annoyed at the collections one being updated wrongly a few times: > https://fedorapeople.org/groups/qa/metadata/release.json > > There's the CurrentFedoraVersion template on the wiki: > https://fedoraproject.org/wiki/Template:CurrentFedoraVersion > > There's also, I think, some variables for 'current' releases in the > Fedora infra ansible deployment. > > There are some fun issues you run up against when you play around in > this sandbox long enough. One, for instance - when *exactly* is a new > Fedora release "released"? Is it when the 'fedora' repo is frozen and > Bodhi is kicked over to pushing new 'stable' updates to the 'updates' > repo instead? (That's Bodhi's definition). Is it when the releases/NN > tree on the public mirror system is available? (That's the one I use, > more or less, for fedfind). Is it when the release announcement goes > out? The point here being, if you think about it hard enough, the > question of what 'states' a distro (or any software product) can be in > is quite a difficult one and probably has a lot of answers. We have a similar challenge even just entirely within AWS. Our mirror model is very different from a typical linux distribution. We're a completely push model rather than mirrors being asynchronous copies. We do it this way so that we can be *certain* when updates hit different locations, as well as control the release velocity, and take action if we discover new sadness during a release. It's the balance between: 1. Customers are frustrated if they know about a package that fixes a security bug but it isn't available in the region where they run their service. 2. Not wanting to have
RE: proposal idea: EOL notifications
Josh Boyer writes: > I really don't think encoding lifecycle information in the > installation itself is the right approach, but it's perhaps the most > tenable one for Fedora. However, until Fedora definitively moves to > using independent lifecycles for their releases, this is a game of > whack-a-mole. We've had this challenge for Amazon Linux as well, and thus our approaches (detailed in other mail) have been to always point to a URL for more up to date information, along with explanatory text to cover different possible phases of support. SuSE has some of this metadata already, but it is very SuSE specific when I looked and we couldn't directly re-use it. ___ 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: proposal idea: EOL notifications
Kevin Kofler via devel writes: > Zbigniew Jędrzejewski-Szmek wrote: >> In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible >> notification when a Fedora stops being supported. Various proposals >> for online checks were discussed in the bug, but I think we might make >> do with something much simpler. > > That will just be perceived as an annoyance. It will not lead to users > actually upgrading their Fedora any more quickly. > >> The advantage of this proposal that it is very simple and will work >> even on machines that don't have network connectivity, > > How does EOL matter at all for machines that do not have network > connectivity? They will not get any updates either way! Cloud instances can be pretty special in this way: you may just be launching the latest image for a particular major OS release, and at some point in time, that is going to no longer get you any security updates. This is a pretty common use case on AWS with customers launching instances in VPCs that only have external connectivity to the S3 repos with OS packages (or not even that if they bake their own AMI with all the packages they need in it), and connectivity to whatever other service/instance that the instance needs to do its work. Often the only other external thing will be some kind of security scanner. ___ 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: proposal idea: EOL notifications
Zbigniew Jędrzejewski-Szmek writes: > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible > notification when a Fedora stops being supported. Various proposals > for online checks were discussed in the bug, but I think we might make > do with something much simpler. We've been thinking a lot in this space in Amazon Linux, and have done some things that are starting to be a bit wider in scope in the AL2022 time frame, and that we've wanted to bring back as ideas to Fedora. One of which is simply how you tell someone there's something new they could move to. If doing so by the command line, you need to somehow work out what X to pass to `dnf system-upgrade ... --releasever=X`, while I'd much rather be able to put it in, say, the motd, and have other tooling be able to know through the same system that "why yes, you are up to date on patches on version X, but version Y is available" The GNOME Software Center parses the hard coded URL of https://admin.fedoraproject.org/pkgdb/api/collections/ which does already have an EOL tag on older Fedora releases, so this could be used today to print warnings all over the place if the format was standard enough and documented... and that other distros could use it easily enough with a custom URL without patching gnome-software... I would be totally in favor of some simple standard metadata we could host somewhere, easily configure into various bits of software that would prominently display it to users (or report back to some central thing, like various agents do with "dnf checkupdate" and "rpm -qa" output, that point to support statements about the OS. We actually have a skeleton design for such a thing (it says what updates and upgrades are available), but we've lagged on both posting to devel@ that it's something we've been working on, and I need to go and poke the person who needs to click the "publish this repo to github" button for the DNF plugin. I'll go do that now, as it would certainly add to this conversation. > https://github.com/systemd/systemd/pull/23924 proposes adding > SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd > e.g. pop up a desktop notification when that date is close, and a > bigger redder notification once it has been passed. The date could be > set to some initial value even on the initial release, and then > adjusted through updates to fedora-release.rpm if our schedule slips. > I guess we could add a notification during boot in systemd itself, but > most users wouldn't see that, so a graphical notification would also > be needed. This could already be done in Fedora with the data from the above URL, but something more generic could be nice, as well as finer grained, as a top level EoL date may not have the full picture. For Amazon Linux, we're wanting finer grained information as well, down to a per-package level, as that gives us the ability to do two things: 1. Clearly communicate an extended support period for a subset of the OS 2. Better ship and communicate life cycle multiple options of major versions of some packages (like MariaDB, PHP, PostgreSQL, Python) with their own support periods following upstream. We've done this by coming up with a "support_info.xml" kind of metadata, to be seen as somewhat related to "updateinfo.xml" except that it contains positive affirmations of support, as well as negative ones. This way, it can be used by external security scanning tooling to work out if there is any path to a particular installed RPM for ever getting another security update. Our first foray into this was with documenting the extension of EoL of Amazon Linux 1: https://github.com/amazonlinux/al1-support-statements and we've used the "explicitly no longer supported" mechanism internally. Our idea has been to use `system-release` (or some other yet to be defined thing) to communicate general OS-wide statements, althoug the nuance is important, and can be interpreted to be exactly what applies to the host you're running on. Arguably you want the warning of "hey, you have PHP7.4 installed, and it's EoL in November" just as much as you want "this whole OS is going out of support in X months". While this per-package level is less relevant for Fedora, it could be a useful mechanism to communicate things that are going to be deprecated in a future release. e.g. we could warn people that at some point the gtk1 they have installed is no longer going to be in Fedora, and where to go to for more information. I'm going to have to apologise for not all of ^ being written up sooner to devel@ as something we've been working on. But we did at least get the source code up for an initial DNF plugin that can parse it and give some tools to users to work out what is (and is not) supported: https://github.com/amazonlinux/dnf-plugin-support-info Our plan is to plug both of these into our update-motd package, which is simply something that writes out motd snippets for pam_motd based on running
Re: Intent to retire containerd in EPEL 7 and co-maintainer request
Maxwell G via devel writes: > Hi everyone, > > I have been de-facto maintaining containerd in Fedora as a member of the go- > sig for a little while now, as the previous maintainer no longer has time to > do. In addition to the Fedora branches, this package also exists on EPEL 7. > That branch has not been maintained for a while and has unpatched CVEs. I am > not interested in maintaining it myself, so unless someone steps up to > maintain it and fix the vulnerabilities, I will retire the package from EPEL 7 > in a week from today, on June 15th. Specifically on this, I'd love to say that someone at Amazon could help here, especially considering we're not too distant from CentOS 7 for a bunch of Amazon Linux 2. Unfortunately I don't think we can given the likely packaging differences, the containerd version differences, and that we don't have infinite time and given a choice between EPEL7 work and jumping into modern Fedora packaging to enhance both Fedora and our Amazon Linux 2022 efforts, I'd pick the latter. > Additionally, I would appreciate co-maintainers to help with the Fedora > branches of containerd, its unbundled go dependencies, and moby-engine > (bundled go package). Long term, I'm not sure I'll have the time or the > interest to maintain these packages. Note that on EPEL 7, containerd bundles > its dependencies; moby-engine is not packaged there. This is 100% somewhere that Amazon Linux can step in and help with. We have a continued interest in the containerd ecosystem working in Fedora like distros (namely Amazon Linux), and the bundled/not-bundled split existing in some working bconds is certainly in our interest (we're likely to continue to bundle dependencies for the forseeable future). I'm going to go chat to some of the people internally who'd be doing the bulk of the work I'm just signing them up for, but would love to sync up on what our respective pain points are at some point soon. ___ 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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Chris Adams writes: > Once upon a time, Jared Dominguez said: >> Looks like they are using vSphere, which supports UEFI VMs. The same is >> true for KVM, Xen and bhyve, so it's more about what feature set cloud >> providers using these hypervisors are choosing to turn on. > > In a way, this is similar to "your router supports IPv6, why don't you > just turn it on?": > > - version considerations: when did $HYPERVISOR start supporting UEFI? > what versions may still be running in some parts of infrastructure? > > - "support" vs. "really support": just because something says it > "supports UEFI" doesn't mean it works right; large-scale hosters need > to do lots of testing of all their supported systems and setups to see > how they actually react > > - internal tooling: just because a hoster is using KVM for example > doesn't mean they just install the vendor software and go; they have > their own internal management systems built on top, calling vendor > APIs to do things > > - presentation: adding user-facing options should always be carefully > considered, especially when they are "change this option and your VM > possibly won't boot" type (so more support tickets) Support tickets don't worry me as much as making breaking changes for customers that possibly result in outages for them do. For example, I don't think it'd ever be possible to flip the default for existing EC2 instance types. Maybe the default for a new major OS version, but there's likely going to be an amount of time before all EC2 instance types support UEFI, and then there'll be customers with a multitude of custom things enabled that don't (at least yet) work with UEFI and will take the easy option of going back to legacy-bios, probably for years. ___ 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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Ben Cotton writes: > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS > > == Summary == > Make UEFI a hardware requirement for new Fedora installations on > platforms that support it (x86_64). Legacy BIOS support is not > removed, but new non-UEFI installation is not supported on those > platforms. This is a first step toward eventually removing legacy > BIOS support entirely. I want to add a few thoughts both from an EC2 perspective, and an Amazon Linux as a downstream of Fedora perspective. Currently, nearly all EC2 instance types will boot by default with legacy-bios. All aarch64 instances are UEFI, and I'd find it unlikely that any new x86-64 instance type would not also support UEFI. But the default for all existing Intel and AMD instance types is legacy-bios. This is largely to preserve backwards compatibility, and at least for existing instance types, I cannot forsee this ever changing. You just don't want to needlessly break customers. Relatively recently, UEFI started becoming an option for some non-aarch64 instance types, and can be selected either at instance launch time, or configured to be part of the AMI. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html There are however a *lot* of instance types, a whole bunch of which are less likely to support UEFI - the documentation gives t2.xlarge as an example of one that only supports legacy-bios. AMIs that don't run on all instance types tend to cause confusion, no matter how clear you document the limitations. It's only now that this is something that's even emerging as something that the EC2 APIs would assist in enforcing. In fact, in Amazon Linux 2022 we went for the decision that for aarch64 we'd require Graviton 2 and x86-64v2 as minimal requirements, and having AL2022 AMIs not boot on a1 instances types did surprise some people, even though we documented it. With things like spot instances, there's a lot of customer demand for "the cheapest possible compute, doesn't matter what or where" to run things that aren't time critical. Now, the interesting thing about Cloud images is that there isn't an installer. In fact, Amazon Linux doesn't have one and we don't package Anaconda anywhere. All users come from a disk image, which we create using separate tooling. Thus, from an AL perspective, if Anaconda were to stop supporting installing for legacy-bios, this wouldn't affect us at all. However, we would have a big interest in having legacy-bios work well to boot the OS, likely for a decent number of years to come (however much I wish this wasn't the case). I guess the interesting balance here is maintenance responsibility as well. I *very* much don't want any of this to read like a request for the community to maintain something that's primarily useful only to a specific vendor. There's a point where if it's functionality that's needed by a vendor, then said vendor has to maintain it, or be very involved in maintaining it. (and for non-EC2 and non-Amazon-Linux input, I have at least one machine at home that run Fedora that don't have UEFI, a HP Microserver of a certain age. Now, maybe it's time for me to upgrade that hardware, but I bet there's a lot of folk who either don't want to do that, or cannot reasonably afford to) ___ 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: F37 Change: RetireARMv7 (System-Wide Change proposal)
Gary Buhrmaster writes: > On Thu, Nov 18, 2021 at 2:32 AM Josh Stone wrote: >> >> On 11/16/21 7:05 PM, Kevin Kofler via devel wrote: >> > Realistically, they will just stick to Fedora 36 forever and just stop >> > updating the devices (or try updating them anyway and get no updates from >> > the server, obviously). >> > >> > Sticking an EOL label on a software release is not going to magically make >> > it go away. >> >> Maybe so, but what can we do? >> >> We already did this for i686 hosts, and I'll bet there are still folks >> running F30 for that, or even EOL versions of currently supported >> arches. They may exist, but they "go away" from the perspective of what >> we choose to support. > > I have occasionally conjectured that there > should be a "last gasp" version of some > core package released into updates for a > version going unsupported that drops a file > into /etc/motd.d that is, essentially: > > "This version of Fedora is no longer supported" > > (and an equivalent banner for desktop login screen) > > That would not mean everyone would see > the message, nor would it stop people using > that version (I would think we do not want > to do so), but it might make it clear(er) to > some that there will be no further updates > in case the individual is not paying close > attention to the Fedora lifecycle. We've been toying with tooling specifically around this in the context of Amazon Linux as (unsurprisingly) we also have people using older versions. We're actually thinking around support periods being different for some packages than others, and being able to programatically communicate this and also alert users. While a motd update is nice, connecting into security and vulnerability scanning tooling is where this really works. The "what packages are supported for how long" part is already up at https://github.com/amazonlinux/dnf-plugin-support-info , and the check-release-update dnf plugin is shipping in AL2022 but we haven't put a nice github repo up yet (let me go and follow up on that now). Probably worth a different discussion and proposal though - something I've been meaning to find the time to write up :) The dynamic motd updates can be done pretty flexibly with pam-motd, with users easily opting out of anything in particular. The way we've been doing it is with a long existing (but not in fedora) package with a simple script called `update-motd`. We've primarily used it to do the nag on what security (and non-security updates) are available for the launched instance. Happy to get a public git repo of the source rather than just SRPMS for this too. Funnily enough though, the simple check of what updates are available can have a decent impact on instance launch time if you're not really careful about where and when that runs. ___ 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
Self Introduction: Stewart Smith
Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon Linux, and thanks to our new direction in basing Amazon Linux on Fedora, also Fedora. I have a (decently) long time Linux history, remembering Slackware 3.5 on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog (yay PowerPC). I’ve spent the vast bulk of my carreer around the free software ecosystem, having spent a long time in the MySQL community, and more recently OpenPOWER, and now working on Amazon Linux. I have a few areas of interest that I’d personally love to contribute around and see progress in the Fedora ecosystem. The idea of atomic updates and rollback with systems like rpm-ostree is quite fascinating from an operational point of view (my personal desktop is currently running Silverblue), and likely fits really well with the versioned (and version locked) repositories we’re doing with Amazon Linux 2022 and beyond. I also think there’s a lot of interesting supply chain assurance we can do to ensure continual and increased confidence in the open source ecosystem and way of development. Then there’s things like performance, boot times (including time-to-first-useful-work), image based deployments (who needs an installer when you can have cloud-init or similar to init things). So, that's a few areas of interest :) With my AWS hat on, I’m pretty excited to see what we do over the coming years with Fedora and Amazon Linux, and growing the number of people who have working on Fedora as part of their day job (and yes, we're hiring). ___ 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: Preventing supply chain attacks via rekor
Björn Persson writes: > I believe Yum has a feature to verify signed repository metadata. I > don't know why it's not used. If that verification would be turned on, > are there any attacks that would still be possible then, that Rekor > could prevent? There's still the classic downgrade attack: point to an older version of the repositories. Enforcing https helps mitigate it by having the client put trust in the certificate owner to run a secure mirror which is kept up to date. You get some protection from *some* downgrade attacks since there's timestamps on repo metadata and if you see older metadata than what you saw last time (yum at least, I haven't double-checked DNF) will complain at you. ___ 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
