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
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
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
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.
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
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
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
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
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
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
: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
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
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
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
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
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,
://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
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
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
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
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
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
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
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:
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
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
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
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'
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,
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
: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
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
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
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
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
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])
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
71 matches
Mail list logo
