Re: Non-responsive maintainer for lz4 package (pjp)

[Smith, Stewart via devel]

> On Dec 9, 2022, at 8:29 AM, Timothée Ravier  wrote:
> 
> Hey folks,
> 
> I've started the non-responsive maintainer procedure for pjp 
> (https://accounts.fedoraproject.org/user/pjp/) with 
> https://bugzilla.redhat.com/show_bug.cgi?id=2152159
> 
> I currently have a pull request that has been blocked for 4 months now: 
> https://src.fedoraproject.org/rpms/lz4/pull-request/5

… which also contains a security fix, CVE-2021-3520 which was rated by RH as a 
Moderate https://access.redhat.com/security/cve/cve-2021-3520 for its products.

So it’d be good to get the update out at some point so that Fedora users can be 
patched.
___
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: Orphaned packages looking for new maintainers

[Smith, Stewart via devel]

> On Dec 19, 2022, at 7:43 AM, Miro Hrončok  wrote:
> 
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/


I took a bunch that we still ship in some Amazon Linux version, and may end up 
going through the package retirement process for some of them in Fedora, as 
some of these are probably a few years beyond any upstream activity.

biosdevname
fros
gconf-editor
gtkhtml3
libbonobo
libbonoboui
libcmpiutil
libgnome
libmodman
liboil
libvirt-cim
libvirt-java
maven-scm
openjpeg
python-cov-core
system-storage-manager
tboot
___
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: Orphaned packages looking for new maintainers

[Smith, Stewart via devel]

> On Dec 19, 2022, at 7:55 AM, Gwyn Ciesla via devel 
>  wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
> 
> 
> 
> I've taken abiword and libgnomeui. As always, co-maintainers welcome.

I grabbed libgnome, happy to co-maintain libgnomeui.
___
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: What should we do about "shopping list" groups in comps?

[Smith, Stewart via devel]

> On Jan 31, 2023, at 2:39 PM, Adam Williamson  
> wrote:
> 
> Hey folks!
> 
> I've sort of happened into doing some maintenance of fedora-comps over
> the last few years. Something that bugs me while working on this is how
> many "shopping list" groups we still have. I'm talking about things
> like the network-server group:

I stumbled into a similar thing recently for the Amazon Linux version of comps. 
It’s had the benefit of at least one time going “oh, we shall start from 
scratch here and not have the accumulated cruft over the past !”, but 
the disadvantage of growing its own (unique!) cruft.

We have notably fewer sections that are shopping lists, but do find value in 
the groups for things that are groups for specific types of images. So we have 
a “container” group which is what the image recipe for the container image 
installs, same with “ami-minimal” and “ami” for the standard and minimal AMIs 
respectively. This lets us do nice things such as modify that over time, not 
require image recipe updates for every possible change etc. The most notable 
being that (in the ideal scenario, which is the normal case), the content of 
each of these images for a particular snapshot of the repo is already built 
into the repo.


>network-server
><_name>Network Servers
><_description>These packages include network-based servers such as DHCP, 
> Kerberos and NIS.
>false
>true
>
>  389-ds-base
>  ahcpd
>  amanda-server
>  babeld
>  cobbler
>  dhcp-relay
>  dhcp-server
>  dnsmasq
>  freeradius
> ...etc etc...
> 
> I'd define a "shopping list" group as one based around a vague theme
> and whose packages are all (or almost all) optional - it's clearly not
> a group that's meant to be installed as a whole, or as a part of a
> system deployment. These groups were instead designed as lists to pick
> individual packages from, in the old anaconda installer interface that
> let you do individual package selection (this is, what, a decade or so
> ago now?), and in software installation apps that similarly let you
> pick packages from the comps groups.
> 
> Neither GNOME Software nor KDE Discover uses these "shopping list"
> groups. (The older GNOME tool that preceded Software did, I think;
> again, that was years ago now). However, dnfdragora (which is the main
> package manager on some smaller desktops, and may still be installed on
> KDE alongside Discover by default, I'm not sure) *does* - you can
> browse by comps group (and 'category', which are collections of comps
> groups intended for this purpose, different from the 'environments'
> used by anaconda) in dnfdragora. Maybe some other GUI packaging tools
> do as well, I'm not sure of any others to check.
> 
> It does not appear to me like anyone besides me does much maintenance
> on these groups. For instance, I don't think anyone but me has touched
> the network-server group since 2019.

I wonder if anyone has used any of them since 2019? :)

I can’t really think of a way to find this out though.. short of doing some 
hefty gymnastics around package download logs...

> These are the groups I'd identify as "shopping list groups":
> 
> cloud-infrastructure
> directory-server
> dns-server (one 'default' package)
> editors
> education
> ftp-server (one 'mandatory' package)
> games (the games spin does not use this group, it has its own list)
> graphical-internet
> graphics
> legacy-network-server
> libreoffice-development
> network-server
> neuron-modelling-simulators
> news-server (one 'mandatory' package)
> office
> server-cfg (one 'default' package)
> sound-and-video
> text-internet
> window-managers

If it helps as a data point, we don’t have any of these groups in Amazon Linux 
and nobody has *ever* asked for them (well.. maybe *once*…)

> there are a few other groups that don't fit strictly into the
> definition but are still of rather dubious usefulness, like the 'web-
> server' group which is rather stuck in the 2000s (including php, php-
> ldap, php-mysqlnd, squid and webalizer by default - is this how anyone
> "deploys a web server" these days?) Being stuck in the 2000s is kind of
> a defining feature of these groups - any time you see a vaguely modern
> package, it's probably been put there by me, replacing something that
> got orphaned. Otherwise most of them seem to have been defined back
> then and rarely or never updated since. (Another example: the last time
> the 'games' group was updated by anyone but me was 2017, adding one
> game; the last update before that seems to have been in 2013).
> 
> So, I'm wondering what folks think we should do with these. We could,
> of course, just get rid of them. But perhaps they are still of value to
> someone? Is anyone still "package shopping" via dnfdragora or some
> other tool, using these groups? Does anyone want to step up and
> actively 'own' some of them for maintenance? Any other thoughts?

Delete them all!

I can’t think of a modern usage that

Re: Firecracker microVM manager

[Smith, Stewart via devel]

On Mar 5, 2023, at 10:19 AM, Kevin Kofler via devel 
 wrote:
> 
> 
> David Michael wrote:
>> - Firecracker can be built with Fedora's libc (glibc), but it is
>> officially unsupported upstream[3].  Functionality would be harmed by
>> not using musl, e.g. seccomp filters are not used.
> 
> Upstream's refusal to write seccomp filters that work with glibc should be a
> red flag. It is definitely possible to sandbox glibc applications with
> seccomp, e.g., Chromium does it. It does need updates/fixes to the seccomp
> rules with almost every new version of glibc, but it is possible.

I’m happy to engage with the Firecracker team and get everyone together to talk 
through the issues.

We did used to package Firecracker for Amazon Linux (in an AL2 Extra), but it 
had literally zero users from our repos (lambda and others build their own). 
This could be due to just Firecracker by itself isn’t too useful without some 
other easy integration with something like containerd. That being said, I’d be 
interested in what use cases people have for it packaged in fedora.
___
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: Orphaning packages (was LibreOffice packages)

[Smith, Stewart via devel]

On Jun 29, 2023, at 7:47 AM, Bastien Nocera  wrote:
> Here is a list of Fedora packages which I maintained or co-maintained which I 
> won't be able to contribute to anymore:
> 
> sloccount

I grabbed sloccount as I’ve found it useful over the years.

It looks the right level of incredibly low maintenance to add to the pile.

___
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

Distro feature macros: a replacement for many %if rhel/fedora/amzn

[Smith, Stewart via devel]

Myself and a few others over in Amazon Linux land have been musing for a while 
about possible improvements that could be done in Fedora to help make Fedora 
and downstream distributions (such as CentOS Stream and Amazon Linux) have an 
easier and simpler time having their individual opinionated choices.

The idea of working out something that could sit in Fedora is that then this 
can work for Fedora enabling/disabling certain features, as well as making 
things like ELN easier, and seed the possibility of an ALN (Amazon Linux Next) 
all from the same upstream Fedora packaging repositories. It’d also make things 
like EPEL, or a hypothetical Extra Packages for Amazon Linux a whole bunch 
simpler as the series of if conditions in a SPEC file could more easily 
illustrate intent.

Simply looking at the subset of Fedora packages that make up Amazon Linux 2023, 
if you "grep -r '%if.*rhel' */*.spec|wc -l” there’s ~850 matches across ~360 
packages, and searching for "grep -r '%if.*amzn' */*.spec|wc -l” there’s ~330 
matches across ~240 packages.

One reason we haven’t gone and upstreamed all these if conditions is that it 
just seems… hacky. Instead, we’d much rather move to some better mechanism that 
ends up with either distro level macros about having features/packages (such as 
"%if 0%{?distro_has_gtk1}” or "%if 0%{?distro_feature_gtk1}”) thus making it 
useful for Fedora changes in enabling and disabling functionality across 
releases.

After all, even across the subset of Fedora packages we have in AL2023, "grep 
-r '%if.*fedora} [><=]' */*.spec|wc -l”, i.e. Fedora version specific changes 
are at ~240 matches across ~120 packages, and especially for things where it 
gates things like python2 support, we could simplify the bconds across a distro 
*significantly* and make it *much* easier to turn these on and off across 
Fedora releases and downstream distros.

Even for something “simple” like the CPU baseline, the `amazon-rpm-config` 
package has the following kind of delta from the `redhat-rpm-config` that sits 
in Fedora, which isn’t really being explicit around the intent, and just makes 
your head hurt when it comes to merging changes:

-%__cflags_arch_x86_64 %[0%{?rhel} >= 9 ? "-march=x86-64-v2" : ""]
+%__cflags_arch_x86_64 %[(0%{?rhel} >= 9 || 0%{?amzn}) ? "-march=x86-64-v2" : 
“"]
….
+# Tuning for aarch64
+%__cflags_arch_aarch64 %[0%{?amzn} ? "-march=armv8.2-a+crypto 
-mtune=neoverse-n1" : “"]

A quick sketch of what this all could look like:

1. distro level (in the [amazon|redhat]-rpm-config package or system-release) 
“has”

e.g. distro_has_gtk1, distro_has_btrfs, distro_has_jack

This would be used to determine if the functionality is present at all in the 
distro, so if you’re building, say in the SDL2.spec it would replace:

%if 0%{?rhel} >= 8 || 0%{?amzn}
%bcond_with jack
%else
%bcond_without jack
%endif

with something like:

%bcond jack 0%{?distro_has_jack}

2. Distro level Feature (in rpm-config or system-release)

e.g. distro_feature_gui

Thus avahi/avahi.spec could replace the following:

%if 0%{?fedora} && !0%{?amzn}
%global WITH_QT3 1
%global WITH_QT4 1
%global WITH_GTK2 1
%endif

%if 0%{?rhel}
%global WITH_MONO 0
%global WITH_QT5 0
%if 0%{?rhel} < 8
%global WITH_PYTHON 1
%endif
%endif

%if 0%{?amzn}
%global WITH_MONO 0
%global WITH_QT5 0
%global WITH_UI_TOOLS 0
%endif

with something more like:

%if 0%{?distro_feature_gui}
%global WITH_QT3 0%{?distro_has_qt3}
%global WITH_QT4 0%{?distro_has_qt4}
%global WITH_QT5 0%{?distro_has_qt5}
%global WITH_GTK2 0%{?distro_has_gtk2}
%global WITH_UI_TOOLS 1
%else
%global WITH_QT3 0
%global WITH_QT4 0
%global WITH_GTK2 0
%global WITH_UI_TOOLS 0
%endif

%global WITH_MONO 0%{?distro_has_mono}
%global WITH_PYTHON 0%{?distro_pkg_feature_avahi_python}

Which is… possibly closer to what a human can parse?

3. Per distro package features (in some include file somewhere? Probably not 
the SPEC file itself… maybe an include to it?)

In the Avahi example above, the WITH_PYTHON is distro dependent for some 
reason, but is local to the package, it isn’t something that’s distro-wide.

Perhaps a package-local distro file?
i.e. adding in something like the following in the package spec file

Source1234: %{_vendor}-macros.inc
%include %{_vendor}-macros.inc

and then having the include have the %if{amzn/rhel/fedora} <>= VERSION logic 
there


Thoughts?
___
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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Smith, Stewart via devel]

> On Jun 22, 2023, at 2:01 AM, Matthew Miller  wrote:
>> 
>>> 
>>> ELN is a build of (some) Fedora packages with EL-specific options, so
>>> it requires Fedora.
>> ELN can exist off an internal non fedora tree. Just depends who is
>> updating the tree.
> 
> Sure, but... that's the _opposite_ of the direction things are going.
> Previously, what happened to make a major RHEL release was:
> 
> 1. Some Fedora Linux Release -> an internal bootstrap
> 2. ...  a year or so of secret work ...
> 3. RHEL Beta
> 4. RHEL Release
> 5. CentOS Linux rebuild
> 6. Internal RHEL build process, internal work on minor release
> 7. RHEL updates appear in publiuc
> 8. CentOS Linux rebuilds of those.
> 
> There's no connection to Fedora beyond the intial fork, and a lot of work
> done inside Red Hat without any transparency.

This was one of our key reasons to look at Fedora as an explicit upstream for 
the next generation of Amazon Linux. Without a feedback loop for contributions 
and changes, it severely limits what you may even want to incorporate, as 
merging this all for the next major release could be a major pain.

Even trivially small things (such as bug fixes) that are beneficial to all (a 
random semi-recent example is making `lshw` not do a DNS lookup) weren’t 
*really* possible to quickly throw a pull request up for before CentOS Streams.

There were other really nice properties of Fedora as well, such as each release 
having a mass-rebuild and thus you can be fairly sure that at any branch point, 
everything is quite likely to all build together.

> Now, CentOS Stream brings that to the surface:
> 
> 1. Fedora Rawhide continually updated
> 2. ELN maintained in parallel, as part of Fedora
> 3. At some point, ELN branched to new CentOS Stream
> 4. ... a year or so of CentOS Stream development in public ...
> 5. RHEL Beta forked from that, released
> 6. Work on RHEL updates visible in CentOS Stream
> 7. Updates appear in CentOS Stream
> 8. Updates released to RHEL
> 
> Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git
> history from Fedora, which is a big improvement in preserving all of the
> incredible, valuable work from Fedora contributors.

Maintaining git history is certainly fantastic from a transparency point of 
view.

Beyond just git trees, we have had a few discussions in the Amazon Linux space 
on what we do with changelogs in the RPMs as well, especially with the 
increasing move to rpm-autospec, which means that git-merge of our own 
trees/rebuilds ends up with the old trick of “Release matches upstream, so it’s 
easy for humans” no longer that useful.

There’s some balance of:
- respect and refer to the amazing work done in the Fedora community
- Don’t give Amazon Linux users the false impression that 
$random_fedora_contributor is who made the change in Amazon Linux that broke 
their $thing - that’s not fun for anybody.
- Be clear as to the changes occurring in an Amazon Linux package update

right now, for AL2023, We have an rpm-autospec-like thing at build time that 
will merge an `amzn-changelog` file that’s present in the git repo with the 
‘%changelog’ in the SPEC file on SRPM build. The aim here is to be able to add 
changelog entries that are amzn specific easily, while not creating merge 
conflicts all the time

It’d be great if we ended up with CentOS Stream and Amazon Linux doing the same 
thing, if only for consistency and being able to set some good expectation / 
good practice for distros downstream from Fedora.

Maybe it’s a question for Fedora developers: how do you *want* downstream 
distributions to behave in this area?

There’s guidelines for https://fedoraproject.org/wiki/Remix and 
https://fedoraproject.org/wiki/Spins_SIG along with 
https://fedoraproject.org/wiki/Releases/FeatureGenericLogos making some parts 
of downstream distros easier to do.

> All of this is the exact opposite of Red Hat preparing to make some new base
> for RHEL. Additionally, this model provides a clean path for
> Red-Hat-opinionated decisions to differ from those we make from Fedora. Take
> BTRFS as an example. Or, the increase in CPU baseline. Like this:

This reminds me of the item on my TODO list of to start a discussion around how 
we can better have distro and package level option switches that both Fedora 
and downstream distros can flip on and off over time. I’ll go do that now...


> Fedora Linux: Community Space
> -
> 
> * Community engineering decisions
> * No special code privileges due to your employer
> * Community-run infrastructure with RH investment, significant resources
>  from Amazon, contributions from other companies
> * Community quality engineering with RH investment
> * Community support
> * No cost
> 
> 
> CentOS Stream: Shared Space
> ---
> 
> * Red Hat Engineering decisions with community input
> * Pull requests from the community, approval from Red Hat engineers
> * Red Hat-provided and maintained infras

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Smith, Stewart via devel]

On Jun 24, 2023, at 8:05 AM, Michael Catanzaro  wrote:
> 
> On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams
>  wrote:
>>> Is it?  At one point, there were considerable gaps in security
>>> updates;
>> RHEL 9.x would get an update while CentOS Stream 9 (as the target for
>> RHEL 9.[x+1]) didn't get a corresponding update for quite a while.  If
>> Stream doesn't get security updates in a timely fashion, it is not at
>> all suitable for production use.
> 
> So here is the reality with security updates. The vast majority of
> security updates are shipped in RHEL 3-9 months after we fix them,
> because minimizing the quantity of updates is an important goal in RHEL
> to reduce update churn for customers, so we only want to release quick
> fixes for issues that pose serious risk. (Most security issues are just
> not very urgent.) This means you get most security fixes drastically
> sooner in CentOS Stream than you would in RHEL. However,
> higher-severity security updates do get fixed in RHEL first. Developers
> are not permitted to fix higher-severity security issues in CentOS
> Stream until after the fix is shipped in at least one RHEL update.
> We're encouraged to do so immediately after the fix ships in RHEL, so
> there *should* only be a minor delay of, say, one or two business days
> for the developer to notice the update has shipped. So in general,
> CentOS Stream *should* generally be ahead of RHEL and ideally only
> slightly behind for the more serious CVEs.

With this development model, what is the thought for those who may want to / be 
able to submit pull requests to CentOS Stream with security fixes?
___
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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Smith, Stewart via devel]

> On Jul 7, 2023, at 7:09 AM, Michael Catanzaro  wrote:
> 
> On Thu, Jul 6 2023 at 09:27:47 PM +0200, Florian Weimer
>  wrote:
>> What about packages which already collect metrics and report them
>> somewhere (not necessarily to Red Hat)?  Would these packages need to
>> change under this proposal?  If not, how do we explain this to our
>> users?
> 
> No, packages that are already collecting their own metrics separately
> would not be affected.

I’d almost prefer we work out a policy where anything of the sort is disabled 
by default, and with a distro-wide standard bcond to not even compile it in as 
an option. (No, I don’t quite know how that could be worded sensibly as a 
policy…. but it’s where I think I’d prefer to start from).

Even well intentioned things can be problematic.

Did you know that “lshw" does a DNS query?

Not only that, it’s a DNS query not to where the distro points to, but 
somewhere out on the internet.

By running “lshw” you’ve now told a DNS server how many machines / people you 
have running “lshw” within some amount of time.

You’ve also now complicated the ability to go “I allow access to the packaging 
repositories for security updates, the one two or three endpoints my 
application needs to talk to, and if any of these machines EVER tries to do any 
other network activity, page people immediately as that can only mean something 
is wrong”. This *really* isn’t an unreasonable thing for people to do, in fact 
I really, really, REALLY want to make it easy for people to do this (and not 
start paging people just because someone diagnosing a problem typed “lshw” or 
something)

For lshw specifically, this is fixed in c9s, Fedora, and upstream now has an 
option to build with this feature disabled:
- https://gitlab.com/redhat/centos-stream/rpms/lshw/-/merge_requests/3
- https://bugzilla.redhat.com/show_bug.cgi?id=2098463
- https://src.fedoraproject.org/rpms/lshw/pull-request/1
- https://github.com/lyonel/lshw/pull/86

Now, this example is obviously not that extreme or anything. It’s arguably less 
information than what’s in your average `curl http://foo`  
request.

But the burden we put on our users is to evaluate each of these is to evaluate 
for them, in their deployment and security context, if they are okay with a 
third party having that information, and that they understand exactly what is 
being done, and what *could* be done with it. It sounds like a lot of work.

An example of this, the countme feature 
https://docs.fedoraproject.org/en-US/fedora-coreos/counting/ / 
https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/dnf-counting/ / 
https://lwn.net/Articles/776327/ that lives as default on in Fedora (on my 
at-home personal Fedora machines too). I made a personal decision for my own 
machines, but when looking at it in the context of building the next (now 
current) version of Amazon Linux, I was faced with a choice: do we go through a 
process of independently working out what our customer thoughts would be on 
this feature, be prepared to set up our own infrastructure around it, how we’d 
communicate about it, as well as ensure all of that meets the security and 
privacy bars we want to uphold….. or do we just not enable it and spend that 
time on other things? We chose to spend the time on other things, as setting 
this up was not critical for us.

But what was fantastic about this was that Fedora was very very very clear 
about the change, how it worked, the efforts gone to etc, and it was so easy to 
flip on/off and was really just in one place, and a place we would *have* to 
modify when we started building our own distro.
___
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: Restricting automounting of uncommon filesystems?

[Smith, Stewart via devel]

> On Jul 24, 2023, at 7:17 AM, Michael Catanzaro  wrote:
> 
> On Sun, Jul 23 2023 at 11:18:45 PM -0400, Demi Marie Obenour
>  wrote:
>> Then the mount needs to be done in a sandbox, such as a KVM guest or
>> sandboxed userspace process.
> 
> Hmmm... I don't think traditional sandboxing accomplishes anything
> here, because we're trying to protect against kernel bugs, not
> userspace bugs, and if the kernel is compromised then you escape the
> sandbox. A KVM virtual machine would solve that, certainly, but that
> sounds really complicated to do? We don't have any precedent for
> spinning up virtual machines to perform normal desktop operations.
> Doesn't that require hardware support anyway? i.e. virtualization might
> be disabled at the firmware level?

Many (most?) cloud environments don’t expose a nested virt capability. That 
being said, even qemu tcg could be a better option for confinement and deliver 
perfectly acceptable performance for a bunch of the use cases.

It’s convenient for me, the user, to be able to use normal Linux utilities to 
read and write files on media for increasingly “oh goodness this makes me feel 
old, I swear that was current just last week” old machines, I don’t exactly 
need multiple hundreds of megabytes per second of IO to that media, I much 
prefer that a random disk image of a 1990s era Mac System Software Beta has as 
many obstacles as possible to being able to inject code into the kernel that I 
also use to log into my bank.
___
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: Restricting automounting of uncommon filesystems?

[Smith, Stewart via devel]

On Jul 24, 2023, at 7:47 AM, Richard W.M. Jones  wrote:
On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote:
I saw that libguestfs has a guestmount(1) tool, and I think this could be
a potential solution.  An exploit against the kernel FS driver would only
grant access to a KVM guest, and the QEMU process can be tightly sandboxed
by means such as seccomp and SELinux.

Right.  guestmount does however use an unholy combination of FUSE and
proxying requests through the KVM guest so this wouldn't be very fast :-/

OTOH it may be fine for the overwhelming majority of use cases, and the 
tradeoff of better hardened systems could also be worth it.

I’ve seen more than one implementation of “Run a Linux container on macOS” that 
ends up using ssh for the console and sshfs as the way to get data back and 
forth… and people seem to be fine with 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Smith, Stewart via devel]

On Jul 24, 2023, at 12:11 PM, Eric Sandeen  wrote:

And frankly that is some of my motivation to find an improvement here. A
small cadre of filesystem developers are near the breaking point trying
to keep up with an army of machines running syzkaller.

There’s also a large flow-on effect to those running production systems and 
what they have to patch and at what pace.

In the current model, where we enable the NTFS (or BeFS, or UFS, or HFS, or 
whatever) file system, every time that has some CVE, we get to release a 
security advisory saying “everybody go update your kernels” and for 99.99% of 
users, it’s code they don’t use, and don’t *want* to even ever have loaded. The 
CIS Hardening Benchmarks all start with “blacklist modules for file systems you 
don’t need”, and module blacklisting is both not an ideal name for the 
functionality, and not exactly a foolproof method.

For a lot of users we are currently:
- likely making them patch needlessly, as it’s code they don’t rely on
- or training them that Important security updates aren’t actually always 
Important, and maybe they can not pay attention to them.

I *really* dislike the latter. The clarity of “you have this software 
installed, there is an Important update to it, this means you must update 
within X time” is wonderful.

One idea we’ve been throwing around is to put all the non-essential (i.e. 
everything but vfat and xfs) file system modules in a different subpackage, and 
sign the modules with a different key, and not trusting that key by default. 
Thus we could issue security advisories just for that subpackage, as well as 
clearly state the level of trust one should place in the code in question.

Combine that with a libguestfs approach with a separate kernel package for its 
guest, and lazy people like me could probably not have to reboot their 
laptop/desktop as often, while simultaneously being more protected from random 
malicious flash drives.
___
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: Should we provide current/previous release links in URLs?

[Smith, Stewart via devel]

On Jul 19, 2023, at 1:24 AM, Stephen Smoogen  wrote:


On Tue, Jul 18, 2023 at 16:43 Kevin Fenzi 
mailto:ke...@scrye.com>> wrote:
On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote:
> As part of the cobbler project testing, we need to test accessing Fedora
> releases with various URLs:
>
> "http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os";,
> "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64";
> "https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64";,
>
> These need to get updated continuously as Fedora progresses.  Could we
> perhaps have a "current" and "previous" (or similar) that tracks the most
> recent and previous release?

Could we? Sure... but... there's a big can of worms around the source of
truth as to what releases are in what state. We could add yet another
thing that we have to manually update here I suppose. Not a super fan of
that.


Having done something similar in the past you find out quickly people will use 
such urls or current/past in configs you don’t expect. Then when Fedora moves 
from 36 to 37 in current you get angry complaints that 5000 systems are broken 
because yum update tried to move a live system from one version to another and 
failed in a hundred different ways.

I was also involved in recently doing such a thing, when we switched the 
“latest” container image of Amazon Linux from Amazon Linux 2 (i.e. circa 2018 
base of things) to Amazon Linux 2023. Looking at the metrics not too many weeks 
after that of what tags were being pulled showed that the majority of those 
relying on “latest” can actually jump from something like Amazon Linux 2 (circa 
2018) to Amazon Linux 2023 without a problem.

But I’ve also seen the other side of things too often too… where people have 
made pretty bad assumptions about what is safe to do.

Ultimately, I’ve come up with the following “OS users deeply believe two things 
that are fundamentally not true. 1) That the OS vendor is flawless and never 
makes a mistake in releasing an update, and 2) That they are using the OS in 
exactly the way it is intended, and exclusively relying on things to stay 
constant that the OS vendor also agrees are things that will stay constant”.
___
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: Staled PRs at https://src.fedoraproject.org/rpms/

[Smith, Stewart via devel]

On Jan 24, 2024, at 11:07 PM, Miroslav Suchý  wrote:
> During my work on SPDX migration I filed hundreds of pull request and as part 
> of that work I always check if there is
> already open PRs for a package.
> 
> It surprised me how many packages has open PR. I understand when there is 
> open PR with blocker or ongoing discussion.
> But I have seen PRs that are open for year+ without any comment from anyone.

This is something that has also caused some amount of frustration amongst the 
Amazon Linux team and can end up as a pretty large de-motivator for 
contributing changes back to Fedora. The context switching back to a long time 
ago, and then likely having to re-adapt your changes can certainly lead to 
choosing the path of not submitting the change as it’s less hassle.

Is a possible solution to tweak how/what provenpackagers can/do do, and perhaps 
surface at a higher level what the global list of “pull requests without 
comments for a month” and “open pull requests mentioning CVE or the word 
security”?  Have it be more of a common pattern to have provenpackagers ack and 
merge CRs across the board? Perhaps some tweaking around SIGs so that experts 
in the ecosystem in question are looking at CRs there?

We have a similar-ish model to how we maintain packages in Amazon Linux 
internally - the key being to avoid SPoF in knowledge, and to enable us to move 
fast when needed (e.g. getting an important security update out to customers).
--
___
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: Explicit dependency on systemd-rpm-macros now required?

[Smith, Stewart via devel]

> On Sep 14, 2022, at 4:17 AM, Tom Hughes via devel 
>  wrote:
> 
>> On 14/09/2022 12:11, Florian Weimer wrote:
>> I see some new build failures in rawhide related to systemd RPM macros:
>> 
>> Processing files: opencryptoki-3.18.0-4.fc38.s390x
>> error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> error: File must begin with "/": %{_unitdir}/pkcsslotd.service
>> […]
>> RPM build errors:
>> File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
>> File must begin with "/": %{_unitdir}/pkcsslotd.service
>> Child return code was: 1
>> EXCEPTION: [Error()]
>> 
>> Is this a package problem (missing dependency on systemd-rpm-macros), or
>> is this something that should be fixed at the buildroot level?
> 
> Guidelines say yes, you do need a BR on that:
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging

I think there was some change “recently” where it needed to start being 
explicit rather than being brought in by some other dependency (possibly a 
change to systemd?). I hit the same thing in a package in Amazon Linux the 
other day, read the packaging guide and wondered how the package had ever built.
___
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