The distros that provide commercial support beside RedHat have been sort
of doing something similar. Canonical provides Ubuntu LTS, a distro with
5 years of development, and then additional 5 years of maintenance for
those with subscription. SUSE, also, 5 years major release support for
OpenS
That's not what is happening on those patches, Leslie. The RH engineers
are adding the patches to the package which is basically how backporting
works (as in all distros that do it), and then adding themselves as the
maintainers that added the patches. Well documented as it should. They
did not
Thank you Mikel, indeed, for keeping helm available in Fedora.
On 7/30/24 9:02 AM, Davide Cavalca wrote:
On 2024-07-27 09:03, Davide Cavalca wrote:
Hey folks,
I have orphaned golang-helm-3. The package currently fails to build
due to broken dependencies, and in general it's been pretty painful
On 7/1/23 12:33, Piotr Szubiakowski wrote:
I think we all have a problem understanding what this announcement
means. I do believe CentOS Stream is awesome software. It has to be
since it's close to what RHEL is. My problem with CentOS Stream is that
it's not a distribution of my choice, and I
will eventually create ABI compatibility issues, and it is
also not what we have been told.
Am I missing something?
Thank you for your feedback.
Regards,
Carlos
On 7/2/23 07:35, Michael Catanzaro wrote:
On Fri, Jun 30 2023 at 11:09:41 AM -0700, Carlos Rodriguez-Fernandez
wrote:
Going forwar
This is actually good news, especially for the CentOS Stream project.
https://almalinux.org/blog/future-of-almalinux/
Quotes:
After much discussion, the AlmaLinux OS Foundation board today has
decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead
aim to be Application Bin
On 7/14/23 00:02, Vitaly Zaitsev via devel wrote:
On 14/07/2023 08:16, Carlos Rodriguez-Fernandez wrote:
After much discussion, the AlmaLinux OS Foundation board today has
decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead
aim to be Application Binary Interface (ABI
Hi all,
I am interested in packaging some golang programs for Fedora (and EPEL),
and I read through the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
My question is more about the reasoning for the recommended handling of
dependencies.
Other language platforms hav
Hi Fabio, Robert-André,
Thank you for the explanation. It makes sense.
Golang has this uniqueness about libs that removes some of the shared
objects pros but I see there are other things at play.
Thank you,
Carlos.
On Thu, Jul 20, 2023 at 1:44 PM wrote:
> On 7/20/23 8:20 PM, Carlos Rodrig
Leon,
I don't think this has ever been about whether a piece of code is
present in version 8 (using your example), but about the free (gratis)
availability of the combination of version 7 with selected backports
from version 8 that has been thoroughly tested by RedHat teams and their
infrastru
Because when they ask “where is the code?”, they are asking a different
question than yours :)
Regards,
Carlos
On Tue, Oct 3, 2023 at 2:30 PM Simo Sorce wrote:
> On Tue, 2023-10-03 at 23:13 +0200, Leon Fauster via devel wrote:
> > Am 03.10.23 um 21:29 schrieb Simo Sorce:
> > > On Tue, 2023-10-0
Hi all,
I have been in the process of becoming a co-maintainer of *libcap*. But
I still need the sponsorship part of it. Hoping it is resolved before
the 6 weeks mark. I got the non-responsive issue approved, the
sponsorship issue, and the PR with updates, tests converted to tmt, and
cleanups
Hi All,
I posted two new packages for review. Feedback is highly appreciated :)
mk-configure
https://bugzilla.redhat.com/show_bug.cgi?id=2257985
libmaa
https://bugzilla.redhat.com/show_bug.cgi?id=2257986
Some context:
I took the orphan package dictd. Dictd depends on libmaa. The dictd spec
wa
Hi All,
The bmake-based mk-configure package review is completed.
Could someone please review libmaa? It is a C language one.
Thank you,
Carlos R.F.
On 1/13/24 12:10, Carlos Rodriguez Fernandez wrote:
Hi All,
I posted two new packages for review. Feedback is highly appreciated :)
mk
Valkey is another fork, sponsored by the Linux Foundation.
https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community
It came out just today.
On 3/23/24 11:35, Jonathan Wright via devel wrote:
KeyDB builds are in Bodhi and ready for testing for all Fedora versi
ng the defacto replacement for redis in most
places.
On Thu, Mar 28, 2024 at 1:09 PM Carlos Rodriguez-Fernandez
mailto:carlosrodrifernan...@gmail.com>>
wrote:
Valkey is another fork, sponsored by the Linux Foundation.
https://www.linuxfoundation.org/press/linux-foundation-launc
I like the idea of the security path as well, where all packages in that
path have upstream subject to higher security standards (that means
helping them to achieve it as well), and greater defense downstream in
any way possible.
Two things that came to mind I shared in another channel:
* no b
Hi Artem,
I disagree that the idea is not appropriate. Ensuring that the tar.gz
you are getting is exactly what it is in the git repo reduces a lot of
risk. So, it makes a lot of sense to get rid of the practice of
distributing tar.gz with pregenerated build scripts not present in the
git rep
Going in that same route, if 2FA becomes mandatory, then we have a
stronger defense of the GPG public key in the user profile. The attacker
would need not only the credentials, but the 2FA device to change the
public GPG.
That then makes one step further possible: enforce commit signing on the
downstream project doesn't get "dirty" during and
after the build, and/or commits are not modified during and after the build.
But this doesn't solve the specific xz problem. That one requires
different kinds of defense techniques.
On 3/31/24 08:10, Carlos Rodriguez-Ferna
Regarding downstream defense, prohibiting blobs or differences between
tars and git repos may be overkill or difficult at this moment, but a
tool to assist maintainers in the identification and analysis of these
situations where attacks may be hidden into can be very helpful.
Regarding the l
Adam,
Is there a way already to achieve test isolation during the rpm build?
Beside doing something ad-hoc with git init or some file system feature,
I was wondering if there is something already available and standardized.
Regards,
Carlos R.F.
On 3/31/24 20:27, Adam Williamson wrote:
On Su
t, so that's why I was thinking of
something more like at the file system level (e.g., a snapshot that it
is then restored, or something like that).
On 3/31/24 23:20, Adam Williamson wrote:
On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
Adam,
Is there a way already
Williamson wrote:
On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
Adam,
Is there a way already to achieve test isolation during the rpm build?
Nothing systematic that I'm aware of, no. It would be tricky because
there is no one universal Standard Test System (not
inary. However, that would still increase the
attack complexity.
[1] https://github.com/carlosrodfern/rpmseclint
On 3/31/24 19:02, Carlos Rodriguez-Fernandez wrote:
Regarding downstream defense, prohibiting blobs or differences between
tars and git repos may be overkill or difficult at this moment
golang, it is mingled with the source code in `_test.go` files. In C,
it depends on the programmers convention.
On 4/1/24 09:29, Adam Williamson wrote:
On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote:
Test isolation is still assuming the attack comes in the test phase.
As I
Chris,
The specific points of entry were evading the strength of open source:
many skilled eyes. Therefore, there is value in programmatically
enforcing that everything used as an input in a build must have been
exposed to *normal opensource workflows*. It is a very simple principle,
yet very
Matthew Miller,
Unit tests, even though in theory developer should mock dependencies to
isolate their code to the maximum, in reality, it is not that clear cut.
Therefore, those unit tests do serve to some extent as a validation that
their code works with the system libraries and platforms pre
Not all commits correspond with a new release downstream, and not all
commit messages are relevant to the end user to be part of the change
log. For example, commits related with increasing gating test coverage
efforts, or setting up gating.yaml itself. Another example is linting
setting and/
Thank you Zbigniew and Miro for the link.
On 4/8/24 02:18, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Apr 07, 2024 at 09:08:49PM -0700, Carlos Rodriguez-Fernandez wrote:
On 4/7/24 21:07, Carlos Rodriguez-Fernandez wrote:
Not all commits correspond with a new release downstream, and not all
I was hesitant to have MFA for a while. Imagine losing a phone with tons
of tokens. What a hassle to recover from that. I found it less than
ideal for practical reasons.
However, I decided instead to buy two Yubikey (primary and backup), and
I add the QRs to both of them with the Yubico App. I
Regarding libteam, the author of the package is the maintainer, email in
bugzilla is different than the one on the project. I wonder if Jiro just
missed the notification that his package is failing to build in F40.
On 4/12/24 07:09, Maxwell G wrote:
Report started at 2024-04-12 13:04:40 UTC
sharing an option just in case it could serve someone that is
hesitating by giving some ideas :).
On 4/12/24 09:47, Adam Williamson wrote:
On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
I was hesitant to have MFA for a while. Imagine losing a phone with tons
of tokens. What a
son wrote:
> > On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
> > > I was hesitant to have MFA for a while. Imagine losing a phone with
> tons
> > > of tokens. What a hassle to recover from that. I found it less than
> > > ideal for practical r
On 4/13/24 01:44, Richard W.M. Jones wrote:
On Fri, Apr 12, 2024 at 04:50:13PM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones said:
So the problem with github is they don't allow you to have 2FA on a
backup device (or rather, it *is* possible, but the process is
ludicrous[1])
Hi Siteshwar,
Thank you for the report. The libcap subtask failed [1] for a known
issue, which is present in libcap 2.69-3 in Fedora rawhide, but was
already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can
confirm it is the case when I run the fedora:41 images. 2.69-8 should
have be
Rodriguez-Fernandez wrote:
Hi Siteshwar,
Thank you for the report. The libcap subtask failed [1] for a known
issue, which is present in libcap 2.69-3 in Fedora rawhide, but was
already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can
confirm it is the case when I run the fedora:41 images
Marián,
I echo your concerns, however, regarding jars with multiple bytecode
versions, aren't java rpm expected to build their sources with one
specific JDK? (per the guidelines) how can multiple bytecode version end
up in the JAR in that scenario?
Regarding the proposal as a whole, I think
On 5/2/24 11:58, Christopher wrote:
On Thu, May 2, 2024 at 6:59 AM Kevin Kofler via devel
wrote:
Carlos Rodriguez-Fernandez wrote:
Regarding the proposal as a whole, I think the proposal idea makes a lot
of sense, but for apps depending on system jar libraries, there should
be a way to speci
:35, Kevin Kofler via devel wrote:
Carlos Rodriguez-Fernandez wrote:
How could that be expressed so that those are caught quickly at build
time? Someone wants to depend on a java lib that has been tested only in
JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa,
for example. Pe
The suggestion for one of the comments of using `/run/fail2ban(/.*)?`
instead of `/run/fail2ban.*` doesn't work?
On 5/4/24 13:05, Richard Shaw wrote:
I still don't understand SELinux and would appreciate an assist!
fail2ban-server is unable to create the socket file
/run/fail2ban/fail2ban.s
I don't think the problem is the "fc" file, but the fact that the file
in /run/fail2ban didn't get relabeled when the users updated, or the
selinux subpackage didn't get updated at all. That explains why it works
on a fresh system.
The specificity of "/run/fail2ban(/.*)?" is better and safer,
2024 at 4:49 PM Carlos Rodriguez-Fernandez
mailto:carlosrodrifernan...@gmail.com>>
wrote:
The suggestion for one of the comments of using `/run/fail2ban(/.*)?`
instead of `/run/fail2ban.*` doesn't work?
I try to be very careful with making changes in SELinux and I don'
Would you want to validate the tar download with the signature provided
by upstream? It has ".sign" files [1]. The public keys should be in here [2]
[1] https://mirrors.edge.kernel.org/pub/linux/utils/raid/mdadm/
[2] https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys
On 5/8/24
as having trouble finding the public key(s). I'll look more into this
> now.
>
> They sign the tar archive before it is compressed, so I'll have to stray
> from the standard way of verifying the sigs in the docs a little.
>
> Thanks for the info.
>
> On Wed, May 8, 2
If a maintainer changes the version, they would need to find the URL and
download the sign file again and do the switcharoo. The key, on the
other hand, won't likely change, and if there is a change, it is good to
detect it. Are you sure you don't want to make the signature also a url
source so
Hi all,
I'll be updating libcap to 2.70 in rawhide. It brings the following:
* A minor enhancement to `cap` output
* A new flag `-f` to `setcap`
* Enhancements to the man pages.
* Minor cleanup in pam_cap internals
No lib API changes.
Regards,
Carlos R.F.
OpenPGP_signature.asc
Description:
Hi All,
The build of libcap in Rawhide is failing the static analysis because of
the stack protection not enabled [1].
```
Hardened: /usr/sbin/captree: FAIL: stack-prot test because stack
protection not enabled (lto:threadentry)
Hardened: /usr/sbin/captree: FAIL: stack-prot test because stack
CGO_CFLAGS="${CFLAGS}" CGO_LDFLAGS="${LDFLAGS}"
GO_BUILD_FLAGS="-buildmode=pie -a -v -x -ldflags='-compressdwarf=false
-B gobuildid'" all
```
Regards,
Carlos R.F.
On 6/13/24 09:30, Carlos Rodriguez-Fernandez wrote:
Hi All,
The build of libcap in Rawhide is fail
h is called right before
the stack protection check is missing a check for "STATE_SKIPPED", but I
may be wrong.
Anyway, I'll be submitting a BUG for annobin-annocheck.
Regards,
Carlos R.F.
On 6/14/24 07:41, Carlos Rodriguez-Fernandez wrote:
So, I found out the stack-prot test was
I found myself too in that situation, where I was forced to rank things
that I don't consider suitable at all. For example, my first and second
choice, I do mean it, ... my 3rd, not at all, however, it will count to
the result as a "3rd" choice, artificially.
I went ahead and clarified my choi
Hello all,
I'll be updating libcap from 2.70 to 2.71 in rawhide[1]. No breaking ABI
changes.
Best,
Carlos R.F.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2321892
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mail
://ieeexplore.ieee.org/abstract/document/8109001
On 10/30/24 10:37 PM, Carlos Rodriguez-Fernandez wrote:
It would be great to see some empirical analysis about binary size
increase, its impact on RAM consumption, and actual speed benefit,
especially on Fedora. I'm having a hard time finding anything abo
It would be great to see some empirical analysis about binary size
increase, its impact on RAM consumption, and actual speed benefit,
especially on Fedora. I'm having a hard time finding anything about it.
Regards,
Carlos R.F.
On 10/30/24 7:46 PM, Neal Gompa wrote:
Hey folks,
I know the idea
Thanks for sharing the report. I looked into the libcap ones and they
all appear to be false positives, but I can see why gcc struggles to
figure it out. I forwarded them to the upstream developer for confirmation.
Thank you,
Carlos R.F.
On 11/14/24 12:47 AM, Siteshwar Vashisht wrote:
Hello,
A few were actually good, and they were fixed right away upstream.
Thanks again for the report!
Carlos R.F.
On 11/14/24 10:14 PM, Carlos Rodriguez-Fernandez wrote:
Thanks for sharing the report. I looked into the libcap ones and they
all appear to be false positives, but I can see why gcc
because of something else?
Thank you,
Carlos R.F.
On 11/14/24 10:14 PM, Carlos Rodriguez-Fernandez wrote:
Thanks for sharing the report. I looked into the libcap ones and they
all appear to be false positives, but I can see why gcc struggles to
figure it out. I forwarded them to the upstream
That went on the wrong thread, sorry, lol.
--
___
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-conduc
Gallagher wrote:
On Sat, Dec 7, 2024 at 12:21 PM Carlos Rodriguez-Fernandez
wrote:
I took sparse, and http-parser.
http-parser in particular is a dead project upstream. However, there is a good
set of packages depending on it. There are also past contributors. If any of
the past contributors want
:28 AM Carlos Rodriguez-Fernandez
wrote:
I agree. This dead package has probably security issues waiting to be
discovered.
There are the other projects as well that would need some relook at its
http-parser dependency and see if it can be dropped: julia, cantor, and
LabPlot.
It looks like the http
Peter said:
> some are *ignored*, some *sit for months without action*, others have
outlined this in the thread as well. If there was a way where people
*put a readme* or something with details I believe it would remove a LOT
of the friction. (emphasis added).
I think there is a frustrati
Hi Jerry,
I made you main admin of the three projects. I stayed as admin in case
you need a hand.
Thank you,
Carlos R.F.
On 1/8/25 4:07 PM, Jerry James wrote:
On Wed, Jan 8, 2025 at 8:29 AM Carlos Rodriguez-Fernandez
wrote:
I'm taking because of their dependencies:
* lrcalc
* Sin
I'm taking because of their dependencies:
* lrcalc
* Singular
* imlib2
* cliquer
If any of the previous admin, committers, or collaborators to those
packages want to take it, please let me know.
Regards,
Carlos R.F.
On 1/7/25 10:46 PM, maxwell--- via devel-announce wrote:
Report start
These are all great points. I also second the Golang change. However,
just to clarify, Go and Rust both generate ELF binaries as well, but
Golang is not comparable to the some of the other examples mentioned. If
you have a vulnerability in a package in Python, for example, you can
deliver one s
I'll take it. Thank you Dmitry.
On 1/23/25 10:38 AM, Dmitry Belyavskiy wrote:
Dear colleagues,
I orphan openssl-gost-engine for personal reasons
--
Dmitry Belyavskiy
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel maili
It looks into the cmd line it was invoked with, then generates the path
based on the u-arch, and then exec the actual binary. There are total
two fork/exec: one to launch the hwcaps-loader (what /usr/bin/foo points
to), and the fork-exec that hwcaps-loader does to run the actual binary.
I'm to
Well, I take that back, there is no second fork, ... just an exec of the
target binary. So, when you launch a program, you would see two exec,
one for the loader itself, and one for the final binary, for what I can
understand.
On 1/12/25 3:54 PM, Carlos Rodriguez-Fernandez wrote:
It looks
I took the golang cgroup ones, since I'm familiarized with it, as well
as with golang. Also trying to start getting into golang packages.
On 1/14/25 5:00 PM, maxwell--- via devel-announce wrote:
olang(github.com/containerd/containerd/cio) = 1.6.23-1.fc41,
golang(github.com/containerd/container
Now I recall, it was happening in Zulu CI for my package, and all I
could do was to ignore it as known issue while waiting for the rpmlint
update. No workaround.
On 1/15/25 8:33 AM, Carlos Rodriguez-Fernandez wrote:
Thank you Miro,
I was certain that I had sent a fix for that to rpmlint
Hi Lukasz,
I took the C lang one. I'm almost done with the review.
Regards,
Carlos R.F.
On 1/1/25 9:41 AM, Łukasz Wojniłowicz wrote:
Hi all,
Anyone willing to swap for equally easy packages?
dmenu-wayland - An efficient dynamic menu for wayland (wlroots)
https://bugzilla.redhat.com/show_b
Thank you Miro,
I was certain that I had sent a fix for that to rpmlint. The problem
went away in my package in the CI (bodhi or Zulu, can't recall), perhaps
rpmlint was updated for the affected CI back then or was removed from
the gating/ci pipelines, or I removed rpmlint from the gating/ci.
Hi all,
The upstream project had changed the license from OpenSSL to Apache
License 2.0 [1]
I'm updating the license in rawhide to reflect the change.
Regards,
Carlos R.F.
1.
https://github.com/gost-engine/engine/commit/c7a9d2902a73bd9f65ae0145ae6f3e37537fc73e
--
___
Some static security tooling that restricts the use of binary files
during the build, check, and install can help here as an alternative to
git archive to mitigate xz kind of attacks (e.g., no binary files use
during the build allowed, and can only be copied during the install as
long as they a
I wonder how this is going to play out in containers with user configs
if "/etc/{passwd,group,shadow,gshadow}" becomes legacy.
On 5/27/25 9:49 AM, Pramod V U via devel wrote:
I am extremely sorry if I am posting to the wrong mailing list, kindly point
that out to me if that's the case.
I'll b
It went generally quick for me.
If it is networking, you may see some large amount of retrans (segment
retrans, syn retrans, etc...) with `sar -n ETCP 1` while you are running
the command. It could also be even before the TCP transmission, during
the name resolution (generally UDP), see what `
75 matches
Mail list logo
