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
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
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
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.
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
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
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
`), but
in 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
. 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 even
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 to achieve
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
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
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-Fernandez wrote:
Going in
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
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
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
acto 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-launches-open-s
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
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
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,
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
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
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
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 forward, yo
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
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
36 matches
Mail list logo
