from:"Carlos Rodriguez\-Fernandez"

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

2024-04-30 Thread Carlos Rodriguez-Fernandez


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 the proposal idea makes a lot 
of sense, but for apps depending on system jar libraries, there should 
be a way to specify that the app depends on a specific java bytecode 
version range. System libraries packages could provide compatibility 
packages, so couldn't those apps just depend on those compatibility 
packages instead? That can become a maintenance burden for those libs, 
though.


Thank you,
Carlos.

On 4/30/24 07:56, Marián Konček wrote:

On 25. 4. 2024 17:46, Michel Lind wrote:



On 4/24/24 11:14 AM, Aoife Moloney wrote:
Wiki - 
https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE
Announced - 
https://discussion.fedoraproject.org/t/f41-change-proposal-drop-mandatory-requires-on-jre-system-wide/114186



[snip]



=== Context ===
Java packages are compiled using `javac` into `.class` files and
composed into `.jar` archives. Jar archives can be used as compile or
runtime dependencies for other packages or can be directly executed
with the java command provided by a JRE.

Jar archives can be executed using the command: `java -jar ${FILE}`.
This command executes the `main` method either specified via CLI or
specified within the Jar manifest file.

Java packages, which serve as libraries only, lack the `main` method
and are not executable. Therefore, there is no requirement on any
specific JRE imposed by the library implicitly.

Sort of... bytecodes do get introduced over time, right? While in 
practice I expect nobody will try and running, say, anything older 
than Java 7 (JSR 7 introduced invokedynamic), should there be a way to 
specify a generic minimum runtime version? I guess the tricky thing 
here is that different JDKs might not be packaged in a way where they 
all implement a common virtual provide that can be targeted


$ fedrq pkgs -P java-headless
java-21-openjdk-headless-1:21.0.2.0.13-3.fc41.x86_64

$ fedrq pkgs -P java-headless -F provides
libjsvml.so()(64bit)
libsyslookup.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
lible.so()(64bit)
libjava.so()(64bit)
libjsig.so()(64bit)
libverify.so()(64bit)
java-21-openjdk-headless(x86-64) = 1:21.0.2.0.13-3.fc41
config(java-21-openjdk-headless) = 1:21.0.2.0.13-3.fc41
java-21-headless = 1:21.0.2.0.13-3.fc41
java-21-openjdk-headless = 1:21.0.2.0.13-3.fc41
java-headless = 1:21.0.2.0.13-3.fc41
java-openjdk-headless = 1:21.0.2.0.13-3.fc41
jre-21-headless = 1:21.0.2.0.13-3.fc41
jre-21-openjdk-headless = 1:21.0.2.0.13-3.fc41
jre-headless = 1:21.0.2.0.13-3.fc41
jre-openjdk-headless = 1:21.0.2.0.13-3.fc41

Every major JDK version introduces a new bytecode version. The bytecode 
version number is part of the .class file format. If an older JVM is 
attempting to load a .class with a higher bytecode version than it 
supports, it fails without attempting to load it.


What you propose makes some sense but I am not completely convinced it 
is a good idea. First of all we need to agree on the meaning of the 
Requires field and what it means to install a package.
* Does one install a package just to look at the files / contents / 
bytecode of the classes? In that case there is no strict requirement on 
the bytecode interpreter (= JVM).
* Does one install a package to **use** it? To load the bytecode using 
some JVM? In that case adding a requirement to the package turns a 
runtime failure (to load the class) into an RPM transaction.


Even if we would agree on the second option, there is another problem: 
an .rpm archive can contain multiple .jar files. a .jar archive consists 
of multiple .class files. Bytecode version is specified for each .class 
file. While a generator that walks over the whole contents and extracts 
the bytecode version numbers could be implemented, should it simply 
reduce the numbers to a maximum? That would possibly prevent the users 
from some valid use cases. Should the packaging guidelines specify that 
an .rpm package may install at most one .jar archive? Although rare, 
there are cases when even .class files in a single .jar have different 
versions. Most notable case: module-info.jar with bytecode version for 
Java 9 and the rest of the source files with version for Java < 9.


Looking at it, I see many questions and potential problems but I also 
find this idea intriguing, to have a generated `Requires: java-bytecode 
 >= 55` or something like that.


This would also require all the JVMs to Provide such a field.

The spirit of this proposal, however, is to allow more freedom for the 
package users at the cost of disabling some implicit behaviours.



=== Different JDKs ===
This proposal is also related to the topic of different JDKs.
Developers may want to use or build packages which use a JDK

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

2024-04-24 Thread Carlos Rodriguez-Fernandez

Actually, I see what the problem is.

The task is for 2.69-8 [1], but the subtask runs for 2.69-3 first to
then have a reference for the diff. So I guess it will work next time a
new version of libcap goes out.

[1] https://openscanhub.fedoraproject.org/task/83/

On 4/24/24 17:11, Carlos 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. 2.69-8 should
have been in the mirrors for more than one week. I'm surprised it wasn't
picked up when this report was run. Will the report be rerun eventually
with an updated version of Fedora 41?

Thank you,
Carlos R.F.

[1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log

On 4/24/24 09:26, Siteshwar Vashisht wrote:

Hello,

This is a follow up on my previous email[1] about OpenScanHub
Prototype for Fedora.
Thank you to those who have provided early feedback. Your help is
truly appreciated!

I am writing this message to get feedback from the community on
possibly new defects identified by static analyzers in Core Critical
Path packages that have changed in Fedora 41.

TLDR: This report[2] contains 14188 identified defects. Please review
the report and provide feedback.

A mass scan was performed this week on the packages that have changed
in Fedora 41. This report[2] contains all the new defects that have
been identified in the core packages listed in Critical Path Packages.
Please review the report and fix or report any defects to upstream
that may be real bugs. Not all defects reported by OpenScanHub may be
actual bugs, so please verify reported defects before investing time
into fixing or reporting them. We hope this is helpful for the
packages you maintain and for the upstream projects. Questions can be
asked on the OpenScanHub mailing list[3]. If you want to see the full
logs of the scans, they are available on the tasks[4] page. User
documentation for performing a scan is available on the Fedora wiki[5].

If the feedback on this report is positive, there may be a possibility
of increasing the scope of scans to cover a wider range of packages.

Please remember this is currently an early production stage for
OpenScanHub scanning. Constructive feedback is appreciated. Thank you!

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/ <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/>

[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
<https://svashisht.fedorapeople.org/f41-22-Apr-2024/>

[3]
https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/ <https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/>

[4] https://openscanhub.fedoraproject.org/task/
<https://openscanhub.fedoraproject.org/task/>

[5] https://fedoraproject.org/wiki/OpenScanHub
<https://fedoraproject.org/wiki/OpenScanHub>

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

OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

2024-04-24 Thread Carlos Rodriguez-Fernandez

Hi Siteshwar,

Thank you,
Carlos R.F.

[1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log

On 4/24/24 09:26, Siteshwar Vashisht wrote:

Hello,

This is a follow up on my previous email[1] about OpenScanHub Prototype
for Fedora.
Thank you to those who have provided early feedback. Your help is truly
appreciated!

I am writing this message to get feedback from the community on possibly
new defects identified by static analyzers in Core Critical Path
packages that have changed in Fedora 41.

TLDR: This report[2] contains 14188 identified defects. Please review
the report and provide feedback.

A mass scan was performed this week on the packages that have changed in
Fedora 41. This report[2] contains all the new defects that have been
identified in the core packages listed in Critical Path Packages. Please
review the report and fix or report any defects to upstream that may be
real bugs. Not all defects reported by OpenScanHub may be actual bugs,
so please verify reported defects before investing time into fixing or
reporting them. We hope this is helpful for the packages you maintain
and for the upstream projects. Questions can be asked on the OpenScanHub
mailing list[3]. If you want to see the full logs of the scans, they are
available on the tasks[4] page. User documentation for performing a scan
is available on the Fedora wiki[5].

If the feedback on this report is positive, there may be a possibility
of increasing the scope of scans to cover a wider range of packages.

Please remember this is currently an early production stage for
OpenScanHub scanning. Constructive feedback is appreciated. Thank you!

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/

[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/

[3]
https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/

[4] https://openscanhub.fedoraproject.org/task/

[5] https://fedoraproject.org/wiki/OpenScanHub

--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-13 Thread Carlos Rodriguez-Fernandez




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]).  If you have your phone as second FA and lose it then
you have to immediately fall back to the piece of paper.


I haven't seen a site with TOTP 2FA allow multiple TOTP codes, they all
just store one.  It's trivial to scan the TOTP code into multiple
devices (depending on the software used, you can sometimes "export" a
TOTP code from one device to another by showing a QR code on the first
device), so that's hardly a "ludicrous" method.


I sometimes think how hard it would be to explain all of this to my
mother.  I don't understand why 2FA needs to be so obscure and clumsy
to use.

Rich.



You got a really good point there. All MFA implementations the industry 
has come up with are less than ideal in one way or the other.




OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-12 Thread Carlos Rodriguez Fernandez

The idea is rather to scan the same QR twice, for two yubikeys, and then
screenshot it and save it securely in case you lose one yubikey and need to
load it into a new one.

On Fri, Apr 12, 2024 at 2:39 PM Richard W.M. Jones 
wrote:

> On Fri, Apr 12, 2024 at 09:47:04AM -0700, 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 hassle to recover from that. I found it less than
> > > ideal for practical reasons.
> >
> > This is one reason most systems provide a sheet of one-time backup
> > codes that you're meant to print out and keep in a safe place, for
> > recovery from exactly that scenario.
> >
> > Alternatively, if you have an old phone or tablet lying around, just
> > install an MFA app on that and enrol it too, lock it in a cabinet, then
> > if you ever lose your primary phone, use it to recover.
>
> 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]).  If you have your phone as second FA and lose it then
> you have to immediately fall back to the piece of paper.
>
> [1] https://github.com/orgs/community/discussions/78027
>
> I really hope we can avoid that mistake.
>
> Rich.
>
> > Also, these days, most authenticator apps support some kind of backup
> > mechanism. FreeOTP lets you back up to a file (which you should, of
> > course, keep somewhere safe and ideally encrypted). Google
> > Authenticator can backup To The Cloud.
> > --
> > Adam Williamson (he/him/his)
> > Fedora QA
> > Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> > https://www.happyassassin.net
> >
> >
> >
> > --
> > ___
> > 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
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> --
> ___
> 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
>
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-12 Thread Carlos Rodriguez-Fernandez

Yes that works too. By the time I was setting up MFA everywhere, and 
doing the code printing, I recall not all systems giving me that option, 
and finding the paper thing not very good as recovery mechanism for me, 
so I went with Yubikeys and my own backup-in-the-cloud mechanism. I was 
just 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 hassle to recover from that. I found it less than
ideal for practical reasons.


This is one reason most systems provide a sheet of one-time backup
codes that you're meant to print out and keep in a safe place, for
recovery from exactly that scenario.

Alternatively, if you have an old phone or tablet lying around, just
install an MFA app on that and enrol it too, lock it in a cabinet, then
if you ever lose your primary phone, use it to recover.

Also, these days, most authenticator apps support some kind of backup
mechanism. FreeOTP lets you back up to a file (which you should, of
course, keep somewhere safe and ideally encrypted). Google
Authenticator can backup To The Cloud.


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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

2024-04-12 Thread Carlos Rodriguez-Fernandez

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

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 be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainersStatus 
Change

container-workflow-tool orphan 2 weeks ago
emacs-htmlize   orphan 3 weeks ago
jolokia-jvm-agent   orphan 0 weeks ago
kio-upnp-ms jgrulich, orphan   5 weeks ago
libteam orphan 0 weeks ago
loudgainorphan 4 weeks ago
mingw-freeimage orphan 0 weeks ago
mrxvt   orphan 4 weeks ago
nextcloud   ichavero, orphan   2 weeks ago
perl-WWW-Google-Contactsorphan 5 weeks ago
php-aws-sdk3orphan 2 weeks ago
php-bantu-ini-get-wrapper   adamwill, orphan   2 weeks ago
php-christophwurst-id3parserorphan 2 weeks ago
php-deepdiver-zipstreamer   orphan 2 weeks ago
php-doctrine-dbal   orphan, remi   2 weeks ago
php-fgrosse-phpasn1 orphan 2 weeks ago
php-giggsey-locale  orphan 2 weeks ago
php-guzzlehttp-guzzle6  orphan 2 weeks ago
php-league-uri-interfaces   orphan 2 weeks ago
php-opencloud-openstack orphan 2 weeks ago
php-opis-closureorphan, remi   2 weeks ago
php-pimple  orphan 2 weeks ago
php-punic   orphan 2 weeks ago
php-ralouphie-getallheaders orphan 2 weeks ago
php-scssphp orphan 2 weeks ago
php-stecman-symfony-console-orphan 2 weeks ago
completion
prometheus-jmx-exporter orphan 0 weeks ago
prometheus-simpleclient-javaorphan 0 weeks ago
python-aiomqtt  orphan 5 weeks ago
python-autoprop orphan 5 weeks ago
python-colorcet orphan 5 weeks ago
python-jose orphan 1 weeks ago
python-limits   orphan 4 weeks ago
python-paramorphan 5 weeks ago
python-pyct orphan 5 weeks ago
python-signature-dispatch   orphan 5 weeks ago
python-vecrec   orphan 5 weeks ago
snakeyaml   mizdebsk, orphan, sbluhm   0 weeks ago
vim-editorconfigorphan 1 weeks ago

The following packages require above mentioned packages:
Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago)
NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, 
danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, 
thaller)
NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 
1.32-4.fc40
NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-11 Thread Carlos Rodriguez-Fernandez

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 also screenshot my 
QRs, tar them, encrypt them with openssl and gpg, and upload them to two 
cloud locations also protected by MFA, and remove them from my computer. 
I repeat that when I add a new QR. I also have a txt together with the 
encrypted tars documenting the commands used to encrypt/decrypt so I 
remember the parameters to use. The reason I do that is to be able to 
load them into a new Yubikey in case I lose one.


There are alternative to Yubikeys if they are too expensive for some. I 
do find them a good investment in general, though. I found having 
Yubikeys (at least two), or other similar devices cheaper than phones, 
to be the most practical way to do MFA. You can even use those same 
Yubikeys to unlock hard drives (luks), and go passwordless for some 
applications.


On 4/11/24 17:09, Gary Buhrmaster wrote:

On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel
 wrote:


2FA in a lot of cases is just access to a different account (e.g. email
or even SMS) and these normally aren't unique. Sure, there are other
ways like FIDO2, but these are not necessarily used (or liked, quite
frankly I know a lot of people who would loose them on a monthly basis,
but still are quite smart about other stuff).


Given that FIDO2 credentials can be stored
on your mobile device (and exchanged with
other devices), if those people are losing their
mobile devices every month they likely have
other issues (including a very expensive
mobile device replacement budget) for which
there is likely no viable solution.

FAS' use of TOTP 2FA is not a great solution
compared to FIDO2, and there are well known
attacks against TOTP 2FA, but even TOTP
2FA can reduce the doorknob rattling exploits.
As TOTP 2FA generators exist for most
mobile devices one will tend to have a
TOTP 2FA generator with one most of the
time.


To the Fedora leadership:

What is the best way to formally propose
that 2FA is required for packagers after
some date (I suppose we could have
different dates for PPs vs others if we
wanted to do that in order to get started
sooner).  Do we need a formal Change
Proposal to be voted on by someone?
It does not really seem like a FESCo
issue to me, but more of a policy issue
that might need to go to the Council?
I have no doubt that such a proposal
will be controversial with some, and
all those issues should get a (re-)airing
in front of those making the decision.
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: convert everything to rpmautospec?

2024-04-08 Thread Carlos Rodriguez-Fernandez

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
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/or configurations. How is that handled with autochangelog?
Can we tell it to skip certain commits? Or should we include it all?

Yes, you can skip %changelog for some commits with '[skip changelog]'
and provide additional content in the commit message which is not part
of the changelog. See
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.

Zbyszek

On 4/7/24 23:01, Miro Hrončok wrote:
> On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:
>>
>> 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/or configurations. How is that handled with autochangelog?
>> Can we tell it to skip certain commits? Or should we include it all?
>
> Put [skip changelog] in the commit message.
>
> 
https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries

>

OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: convert everything to rpmautospec?

2024-04-07 Thread Carlos Rodriguez-Fernandez



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/or configurations. How is that handled with autochangelog? 
Can we tell it to skip certain commits? Or should we include it all?


Regards,
Carlos.

On 4/7/24 08:15, Zbigniew Jędrzejewski-Szmek wrote:

Hi everyone,

I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.

All my packages have been converted, so in day-to-day work, I don't
even think about %changelog. When working with other packages, I'll
forget to update the Relase and/or %changelog. Today I was rebasing
some pull requests in pagure, and the _only_ conflicts that I had were
about Release and %changelog.

I think it's time to switch to rpmautospec completely.
Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
   (e.g. when they want to push some fix or separately from other
work)
- people submitting pull requests against src.fp.o MAY also
   include a conversion in the pull request and packagers SHOULD
   merge it.

(FTR, 'rpmautospec convert' does the conversion, incl. the commit
to dist-git. Manual conversion should not be used.)

Zbyszek
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Carlos Rodriguez-Fernandez


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 present in the 
targeted configuration. I think it is valuable to run them during the 
rpm builds, and contribute upstream when they break.


On 4/1/24 14:11, Matthew Miller wrote:

On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:

Unit tests are something for upstream developers. They should NEVER be run
in a distribution build.


Even in the few little packages I'm still responsible for, I sometimes see
unit test failures. The developer ran the tests, but not on S390. Or, with a
different timezone database than current in Fedora. Or etc.



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Carlos Rodriguez-Fernandez


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 powerful: let's flag everything that can evade review: 
basically, tar.gz must be equal in content to what it is browseable on 
the git repository, and also blobs must be flagged for additional 
analysis, because released tar.gz and blobs are not normally reviewed on 
a opensource workflow.


Those problems can be codified in a tool (which it is already done in a 
proof of concept to show that it is simple to do and possible), or the 
approach can be changed all together to something like source-git?


On 4/1/24 18:47, Chris Adams wrote:

Yeah.  This was clearly an attack targeted at Fedora and Debian; trying
to fix the specific point of entry is a losing battle, as at the end of
the day, Fedora will still be taking code from upstreams and
distributing it to systems far and wide.  The particular use of test
and autoconf files to try to hide the attack may be novel, but there are
other ways it could have been done.  If there's easy and minimal-impact
ways to help (which I haven't really seen suggested), that's good to
look at, but putting lots of effort into how tests are run or wholesale
changes to configuration seem to not be all that useful.

However, it's a good trigger to review Fedora's security approach in
general (like 2FA use).


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Carlos Rodriguez-Fernandez

Understood. However, at least for those unit tests run in the %check, it 
is going to be almost unfeasible, because of the variability of the way 
things are done in the different programming ecosystems. In Java, unit 
tests are nicely separated in a different folder (i.e., `src/test`), 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 initially suggested it, it does not. My suggestion was that we
ensure the test code is not available to the prep / build / install
phases *at all*, and is only made available to the test phase.


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Carlos Rodriguez-Fernandez

Definitely this attack leveraged places where eyes don't look:
distributed tar.gz and blobs.

I put the PoC to flag those two in github[1]

Example output:

$ ./rpmseclint tests/rpmseclint-test.spec
-Diff-
~ test.txt
+ additional.txt
+ blob.txt.gz
-Blobs
application/gzip blob.txt.gz

Now, against the PoC itself, the diff part can be totally avoided by
using generated tars. Not all projects are in github, but those that
do... The other way is by using source-git?

Regarding the blobs part, ... an attack could still manage to fool
`file` with a crafted binary. 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, 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 latter, where you want to find diff between tars and git
repo content, someone may say "let's just use the github API to pull the
tar", but not all projects use github, or have that feature. So, I still
think there is value in these tools.

I started working on a PoC personal minitool named rpmseclint that
utilizes the "VCS" tag to pull the git repo, and the tar, and compares
and flags things for further review. Right now, I'm just focused on
blobs, and files/directories differences. The intention is to use it at
least right before a rebase. I'm just planning to personally use it to
get a "feel" for it (and help myself), but open to anyone wanting to
explore this idea.

In general, I think the idea of codifying security practices expertise
in tools to assist maintainers with detection and analysis has great
value; even if it is not enforcing anything at the moment. The
maintainer could then explicitly add found problems to an "ignore" list
after the analysis, and explain the "why" in the git commit body
message, and perpetuate the reasoning in the git history of the
downstream project. There is already a lot of best practices codified in
the gating pipelines, and I have found them extremely useful myself.

Regards,
Carlos R.F.

On 3/30/24 02:37, Richard W.M. Jones wrote:

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.

(1) We should routinely delete autoconf-generated cruft from upstream
projects and regenerate it in %prep. It is easier to study the real
source rather than dig through the convoluted, generated shell script
in an upstream './configure' looking for back doors.

For most projects, just running "autoreconf -fiv" is enough.

Yes, there are some projects that depend on a specific or old version
of autoconf. We should fix those. But that doesn't need to delay us
from using autoreconf on many projects today.

In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates. I don't fully understand why that is.

(2) We should discourage gnulib as much as possible.

In libvirt we took the decision a few years ago to remove gnulib.
It's extremely convoluted and almost no one understands how it really
works. It's written in obscure m4 macros and shell script.

It's also not necessary for Linux since gnulib is mainly about
porting to non-Linux platforms. There are better ways to do this.

In the xz case it was a gnulib-derived script which was modified to do
the initial injection (original:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD).

(3) We should have a "security path", like "critical path".

sshd is linked to a lot of libraries:

/lib64/libaudit.so.1 audit-libs
/lib64/libc.so.6 glibc
/lib64/libcap-ng.so.0 libcap-ng
/lib64/libcap.so.2 libcap
/lib64/libcom_err.so.2 libcom_err
/lib64/libcrypt.so.2 libxcrypt
/lib64/libcrypto.so.3 openssl-libs
/lib64/libeconf.so.0 libeconf
/lib64/libgcc_s.so.1 libgcc
/lib64/libgssapi_krb5.so.2 krb5-libs
/lib64/libk5crypto.so.3 krb5-libs
/lib64/libkeyutils.so.1 keyutils-libs
/lib64/libkrb5.so.3 krb5-libs
/lib64/libkrb5support.so.0 krb5-libs
/lib64/liblz4.so.1 lz4-libs
/lib64/liblzma.so.5 xz-libs
/lib64/libm.so.6 glibc
/lib64/libpam.so.0 pam-libs
/lib64/libpcre2-8.so.0 pcre2
/lib64/libresolv.so.2 glibc
/lib64/libselinux.so.1 libselinux
/lib64/libsystemd.so.0 systemd-libs
/lib64/libz.so.1 zlib / zlib-ng
/lib64/libzstd.so.1 zstd

Should we have a higher level of attention to these packages? We
already have "critical path", but that's a broa

Re: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Carlos Rodriguez-Fernandez


I created a discussion issue for this idea:

https://github.com/rpm-software-management/rpm/discussions/3009

I think it worth pursuing further.

On 4/1/24 04:46, Neal Gompa wrote:

On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
 wrote:


On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam 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 within a
single language ecosystem, let alone across all of them). Currently
you'd have to design something unique, if you wanted to implement this
for your package.


If we wanted to pursue that, I'd suggest the following:
remount $RPM_BUILD_ROOT read-only for the %check phase
(or maybe overmount it with a writable overlayfs that is thrown
away after %check finishes, and warn if any modifications were made.)
%check is executed after %install, so everything should be in place
before %check, and %check may be skipped, so no modifications to
installed files should be done in %check.

Considering possible implemention details, machinectl has 'bind' and
'bind --read-only' that might be useful here. But mock uses
systemd-nspawn in a way that does register the container with machined.
So maybe it'd be more reasonable to just execute a mount command directly
from mock.

This is independent of the test system and does not require splitting
of the test sources.



Another thing to consider is making RPM unshare each build phase like
it can for scriptlets now at install time[1].

Sandboxing and limiting in rpmbuild itself like we can with rpm can
also help with this. I believe moss[2]' boulder tool does this.

[1]: https://github.com/rpm-software-management/rpm/pull/2666
[2]: https://github.com/serpent-os/moss/tree/main/boulder




--
真実はいつも一つ！/ Always, there's only one truth!
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-04-01 Thread Carlos Rodriguez-Fernandez



Test isolation is still assuming the attack comes in the test phase. The 
attack can come in the `make`, or in the `make install` too. That's why 
the idea of other techniques being discussed are still valid, but 
perhaps not abstracted out enough for a wider defense.


However, the test isolation concept is a good defense. Once the build 
artifacts is generated, the integrity of the build artifacts must be 
ensured during any post build phase. Some tests do expect to be executed 
right after the build, when the build artifacts are still in specific 
directories within the source root, 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 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 within a
single language ecosystem, let alone across all of them). Currently
you'd have to design something unique, if you wanted to implement this
for your package.

I suppose one approach would be to split the sources-required-for-build
and the test suite into Source0 and Source1 (respectively) and only
extract Source0 during %prep. Don't extract Source1 until %check (i.e.
after %build and %install are already done). I'm just spitballing,
though, haven't checked if this is really practical.

Of course, another approach is to really do what Kevin suggests and not
ship the test suite in the package source at all, but instead run the
tests via Fedora CI, and configure the package to be gated on that CI
check (so it wouldn't go to stable without the tests passing). But
that's rather a different approach (and would still require 'custom'
work to cut the tests out of the source, or at least delete them before
running the build).

And I still think at this point we are falling into the trap of
thinking too specifically about an attack vector which just *happens*
to be the one chosen in *this specific instance*. It's still
worthwhile, on some level, for someone to think about that kind of
hardening, of course. I am just not convinced it is the most useful
thing Fedora could be doing right now in the general area of "supply
chain hardening".


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-03-31 Thread Carlos Rodriguez-Fernandez


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 Sun, 2024-03-31 at 20:12 +0200, Kevin Kofler via devel wrote:

Adam Williamson wrote:

I would argue there's a danger of getting too tied up in very specific
technical details of this attack.


But the fact is:

What WOULD have stopped this attack: (one or more of:)
* Deleting ALL unit tests in %prep (and then of course not trying to run
them later).


This comes with the huge cost that we no longer have any idea if many
things actually work in Fedora. There are much better options here,
such as ensuring the package build process *isolates* the test data
from the compile process without just *removing* it. but again, this is
getting far too tied up in the details of this *one* attack. it's the
"everyone has to take their shoes off at the airport forever" mistake:
just because the *last* attack involved a binary test file, does not
mean the *next* one will. This is also known as preparing for the last
war, in military strategy.


* Deleting ALL files automatically generated or imported by autotools in
%prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would
NOT have done the right thing here. Delete the files, THEN run autoreconf.)


No. This would not have avoided the attack, because it would not have
regenerated the malicious file. We have already established that.


* NOT patching OpenSSH downstream to link it against libsystemd against
upstream's recommendation.


Again, this is far too tied to the specific attack. I'm not interested,
as I said, in Monday morning quarterbacking this specific attack. I'm
interested in the question of what are the most immediate and effective
ways Fedora can lower its likelihood to be directly targeted in a
supply chain attack *in future*. Not the last one.


What WOULD have greatly reduced the impact of this attack:
* NOT enabling updates-testing by default for Branched releases.


This would only have helped by coincidence - the coincidence that the
compromise was discovered so quickly. Otherwise, we were busy trying to
get this update pushed stable as fast as possible, because rwmj wanted
that. If the compromise had happened to be caught a few days later, the
update would have been pushed stable anyway. Our gating and manual
testing processes are not designed to catch security issues, and
certainly do not reliably do that job. They did not in this case. So it
seems wrong, to me, to suggest we should rely on them to do it in
future. Thus I disagree that any possible security benefit gained by
doing this would outweigh the substantial disadvantage that we wouldn't
get testing of stuff promptly any more.


What WOULD NOT have stopped this attack: (any or all of:)
* 2FA. GitHub already enforces 2FA. It did NOT stop this attack.


Again. I'm not interested in what, with hindsight, might have stopped
the attack that already happened. We know for sure that weak
authentication processes absolutely are a giant flashing ATTACK HERE
neon sign for *future* attackers.


* Any stricter vetting of Fedora contributions. The attack was performed
upstream, NOT in Fedora.


See above.


* More distrust of new Fedora contributors. The offending upgrade was
imported by a TRUSTED Fedora contributor. The untrusted new person operated
upstream, NOT in Fedora.


See above again.


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-03-31 Thread Carlos Rodriguez-Fernandez

Regards,
Carlos R.F.

On 3/30/24 02:37, Richard W.M. Jones wrote:

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.

For most projects, just running "autoreconf -fiv" is enough.

Yes, there are some projects that depend on a specific or old version
of autoconf. We should fix those. But that doesn't need to delay us
from using autoreconf on many projects today.

In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates. I don't fully understand why that is.

(2) We should discourage gnulib as much as possible.

In libvirt we took the decision a few years ago to remove gnulib.
It's extremely convoluted and almost no one understands how it really
works. It's written in obscure m4 macros and shell script.

It's also not necessary for Linux since gnulib is mainly about
porting to non-Linux platforms. There are better ways to do this.

(3) We should have a "security path", like "critical path".

sshd is linked to a lot of libraries:

/lib64/libaudit.so.1audit-libs
/lib64/libc.so.6glibc
/lib64/libcap-ng.so.0 libcap-ng
/lib64/libcap.so.2 libcap
/lib64/libcom_err.so.2 libcom_err
/lib64/libcrypt.so.2libxcrypt
/lib64/libcrypto.so.3 openssl-libs
/lib64/libeconf.so.0libeconf
/lib64/libgcc_s.so.1libgcc
/lib64/libgssapi_krb5.so.2 krb5-libs
/lib64/libk5crypto.so.3 krb5-libs
/lib64/libkeyutils.so.1 keyutils-libs
/lib64/libkrb5.so.3 krb5-libs
/lib64/libkrb5support.so.0 krb5-libs
/lib64/liblz4.so.1 lz4-libs
/lib64/liblzma.so.5 xz-libs
/lib64/libm.so.6glibc
/lib64/libpam.so.0 pam-libs
/lib64/libpcre2-8.so.0 pcre2
/lib64/libresolv.so.2 glibc
/lib64/libselinux.so.1 libselinux
/lib64/libsystemd.so.0 systemd-libs
/lib64/libz.so.1zlib / zlib-ng
/lib64/libzstd.so.1 zstd

Should we have a higher level of attention to these packages? We
already have "critical path", but that's a broad category now. These
seem like they are "security path" packages, an intentionally small
subset associated with very secure services which are enabled by
default.

These are just my thoughts on a Saturday morning. Feedback welcome of
course.

Rich.

Re: Three steps we could take to make supply chain attacks a bit harder

2024-03-31 Thread Carlos Rodriguez-Fernandez

BTW, adding comments to myself, the signed commits and their
verification takes care of problems 2FA doesn't. First, ensure
authorship information (2FA doesn't leave a mark in the commit), and
protects the integrity of the downstream source: the build can ensure
that the checked out 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-Fernandez wrote:
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. That makes authorship of changes non repudiateable
(that is, important changes like `sources`, all patches, specs, etc...),
and also allows the build to check that all commits between the last
release and the current build are signed by the committers of the
project. This can be done by having the build importing the public GPGs
of the committers of the downstream project from pagure/FAS and
checking, again, the commits since the last release. The downstream
project *source code* would be effectively signed, so the signed rpm
then would carry even a higher assurance: "this artifact was built by
Fedora Infrastructure", but also "all the downstream sources used to
make it are assuredly coming from the maintainers."

It is definitely an additional hassle for the maintainers, but there is
value in it, especially in this day and age.

On 3/31/24 01:58, Adam Williamson wrote:

On Sat, 2024-03-30 at 09:37 +, Richard W.M. Jones wrote:

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.

I don't disagree with Richard's list. However...more in regards to some
of the grandiose ideas in later posts than Richard's list...I think
we're in danger of building castles in the sky while not cleaning up
the poop in our backyard, here.

Before we start in on the grand fantasies about converting the world
off autotools or banning binaries in repos or centralized source depots
authenticated by a committee of Top People, can we remember:

1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
COMPULSORY 2FA FOR FEDORA PACKAGERS*.

2. Our process for vetting packagers is, let's face it, from a security
perspective almost *comically* patchy. There are 140 sponsors in the
packager FAS group. Any one of those people - or someone who
compromises any one of those 140 accounts - can grant any other person
on earth Fedora packager status. Our policy on how they should do this
is
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection
. The words "trust" and "identity" do not appear in it. There is,
AFAIK, no policy or procedure by which inactive sponsors have this
power removed. There is no mandatory 2FA policy for sponsors.

3. We have no mechanism to flag when J. Random Packager adds
"Supplements: glibc" to their random leaf node package. As a reminder,
*we are a project that allows 1,601 minimally-vetted people to deliver
arbitrary code executed as root on hundreds of thousands of systems*,
and this mechanism allows any one of those people to cause the package
they have complete control over to be automatically pulled in as a
dependency on virtually every single one of those systems.

4. Our main auth system was written years ago by someone who no longer
contributes and nobody is really actively maintaining it[0].

These are just the ones that leap to my tired mind at this moment. I'm
sure we can think of many more things we should probably look at before
we start pontificating (or, worse, lecturing) about how things should
be done upstream of us.

[0]: https://pagure.io/ipsilon/commits/master

Re: Three steps we could take to make supply chain attacks a bit harder

2024-03-31 Thread Carlos Rodriguez-Fernandez

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.

It is definitely an additional hassle for the maintainers, but there is
value in it, especially in this day and age.

On 3/31/24 01:58, Adam Williamson wrote:

On Sat, 2024-03-30 at 09:37 +, Richard W.M. Jones wrote:

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.

1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
COMPULSORY 2FA FOR FEDORA PACKAGERS*.

4. Our main auth system was written years ago by someone who no longer
contributes and nobody is really actively maintaining it[0].

[0]: https://pagure.io/ipsilon/commits/master

Re: Three steps we could take to make supply chain attacks a bit harder

2024-03-30 Thread Carlos Rodriguez-Fernandez


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 repo that has not been reviewed, without an audit trail implicit in 
the git history, and without a clear non-repudiateable authorship. 
Ignoring them and regenerating them is a step forward.


I bet the JT user would not have been able to put the attack in the git 
source code without Lasse seeing it, or other developers, or tools 
eventually seeing it, sooner than if it had been obfuscated in the 
"release" downloads (as it was).


Regarding the multiple eyes, that is not the goal, but the goal is 
multiple *skilled* eyes.


At the end of the day, this is not about building a bullet-proof system 
since that's unrealistic, but a system that makes it very hard by 
setting up tools and processes that mitigate the risk significantly.


Regards,
Carlos.

On 3/30/24 12:43, Artem S. Tashkinov via devel wrote:

And of course, would be great to employ all the methods


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Three steps we could take to make supply chain attacks a bit harder

2024-03-30 Thread Carlos Rodriguez-Fernandez

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 binary blobs in the upstream, or no blob referred to in the source 
built, or referred to in the build tools
* diffoscope should show no difference except file stats between the 
tar.gz being pulled by the spec, and the source brought with a git clone.


Both things could be automated with tools.


On 3/30/24 08:58, Miroslav Suchý wrote:

Dne 30. 03. 24 v 10:37 dop. Richard W.M. Jones napsal(a):

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.


4) Fetch build artifacts before executing tests

https://github.com/rpm-software-management/mock/issues/1352


(3) We should have a "security path", like "critical path".

Generally good idea. But several packages that JiaT75 GH-starred were:

* doxygen - when you infect this, you have open path to 700 Fedora 
packages, including gcc.


* squashfs-tools - when you infect this, you have open path to all 
images (just example, not sure if our toolchain use this or -ng version).


So the security patch should be much wider.



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Redis will no longer be OSS... now what?

2024-03-28 Thread Carlos Rodriguez-Fernandez


So, valkey is then the one the AWS employee did.

Thank you Jonathan for the work on this.

On 3/28/24 11:13, Jonathan Wright via devel wrote:

This is the one previously known as "PlaceHolderKV".

I forgot to mention but redict is packaged and ready for testing in 
Bodhi: https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc 
<https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc>


I'll be packing up valkey as soon as they have a tagged release.

After following redict and valkey closely for the past week or so I'm 
anticipating valkey becoming 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-launches-open-source-valkey-community
 
<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
versions
 > + EPEL8/9.
 >
 > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
<https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>
 > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
<https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>>
 >
 > I'm still keeping an eye on, and chatting with the creators of
the other
 > two, redict and the unnamed one from an AWS employee and will
package
 > them when they have official builds.
 >
 > In the meantime I'd welcome any testing on the KeyDB packages in
Bodhi.
 >
 > On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster
 > mailto:gary.buhrmas...@gmail.com>
<mailto:gary.buhrmas...@gmail.com
<mailto:gary.buhrmas...@gmail.com>>> wrote:
 >
 >     On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
 >     mailto:devel@lists.fedoraproject.org>
 >     <mailto:devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>>> wrote:
 >
 >      > We will see whether that or redict will get the most
attention. Cloud
 >      > companies like Amazon will probably prefer BSD, whereas
 >     contributors worried
 >      > about another "Redis, Inc." coming up and taking their
forked code
 >      > proprietary too will most likely prefer the LGPL fork (redict)
 >     (unless they
 >      > are unhappy about the use of version 3.0 only of the LGPL
by that
 >     fork).
 >
 >     "It is hard to make predictions, especially about the future",
 >     but it appears that many of the recent non-redis contributors
 >     are cloud company entangled (and were previously willing to
 >     contribute under the BSD-3-Clause license).
 >     --
 >     ___
 >     devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
 >     <mailto:devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>>
 >     To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
 >     <mailto:devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>>
 >     Fedora Code of Conduct:
 > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
 >   
  <https://docs.fedoraproject.org/en-US/project/code-of-conduct/

<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>>
 >     List Guidelines:
 > https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
 >     <https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>>
 >     List Archives:
 >
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>>
 >     Do not reply to spam, report it:
 > https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new

Re: Redis will no longer be OSS... now what?

2024-03-28 Thread Carlos Rodriguez-Fernandez


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 versions 
+ EPEL8/9.


https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2 



I'm still keeping an eye on, and chatting with the creators of the other 
two, redict and the unnamed one from an AWS employee and will package 
them when they have official builds.


In the meantime I'd welcome any testing on the KeyDB packages in Bodhi.

On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster 
mailto:gary.buhrmas...@gmail.com>> wrote:


On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
mailto:devel@lists.fedoraproject.org>> wrote:

 > We will see whether that or redict will get the most attention. Cloud
 > companies like Amazon will probably prefer BSD, whereas
contributors worried
 > about another "Redis, Inc." coming up and taking their forked code
 > proprietary too will most likely prefer the LGPL fork (redict)
(unless they
 > are unhappy about the use of version 3.0 only of the LGPL by that
fork).

"It is hard to make predictions, especially about the future",
but it appears that many of the recent non-redis contributors
are cloud company entangled (and were previously willing to
contribute under the BSD-3-Clause license).
--
___
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




--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 

--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Request for Review for Two New Packages

2024-02-06 Thread Carlos Rodriguez-Fernandez



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-configure
https://bugzilla.redhat.com/show_bug.cgi?id=2257985 
<https://bugzilla.redhat.com/show_bug.cgi?id=2257985>


libmaa
https://bugzilla.redhat.com/show_bug.cgi?id=2257986 
<https://bugzilla.redhat.com/show_bug.cgi?id=2257986>



Some context:

I took the orphan package dictd. Dictd depends on libmaa. The dictd spec 
was pulling libmaa source and building it, and linking to it statically. 
Libmaa is not available as a package in Fedora.


I am separating them and making libmaa available as a dynamic library 
and its own package.


libmaa builds with mk-configure. The new dictd being developed builds 
with mk-configure as well. For that reason, I went ahead and created 
also that new mk-configure package.


Both packages are necessary to update dictd going forward.

Thank you,
Carlos R F.


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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

Request for Review for Two New Packages

2024-01-13 Thread Carlos Rodriguez Fernandez

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
was pulling libmaa source and building it, and linking to it statically.
Libmaa is not available as a package in Fedora.

I am separating them and making libmaa available as a dynamic library and
its own package.

libmaa builds with mk-configure. The new dictd being developed builds with
mk-configure as well. For that reason, I went ahead and created also that
new mk-configure package.

Both packages are necessary to update dictd going forward.

Thank you,
Carlos R F.
--
___
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: Inactive packages removed from packager group

2023-11-19 Thread Carlos Rodriguez-Fernandez


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 and its COPR build passing.


The sponsorship issue: https://pagure.io/packager-sponsors/issue/602

I would appreciate if someone is willing to help me with the sponsorship 
part :-)



Thank you,
Carlos R.F.


On 11/18/23 13:08, Kevin Fenzi wrote:

Hi all,

Today, 2023-11-18, we have removed inactive packagers
from the packager group.

This is in accordance with the FESCo policy on inactive packagers:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/

If the removed user is 'main admin' for a package, this package
will be orphaned. If there are co-maintainers for the package,
one of them should take the role of 'main admin',
by clicking "✋ Take" on
`https://src.fedoraproject.org/rpms/`".

Otherwise any packager may take the package while it's orphaned.
After 6 weeks, the package will be retired.
After another 8 weeks, a new review is needed to unretire it.
see 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
for more details.

More details available in https://pagure.io/fedora-infrastructure/issue/11621

Packages that have been orphaned are:

rpms/gtksourceview5
rpms/python-typing-inspect
rpms/xorg-x11-drv-qxl
rpms/coin-or-lemon
rpms/fish
rpms/nvme-cli
rpms/u2f-hidraw-policy
rpms/virtme
rpms/elementary-onboarding
rpms/vala-language-server
rpms/perl-MooseX-Role-Matcher
rpms/perl-Net-Google-AuthSub
rpms/drupal7-advanced_help
rpms/drupal7-auto_nodetitle
rpms/drupal7-calendar
rpms/drupal7-ckeditor
rpms/drupal7-date_ical
rpms/drupal7-email
rpms/drupal7-features
rpms/drupal7-feeds
rpms/drupal7-flexifilter
rpms/drupal7-footnotes
rpms/drupal7-google_analytics
rpms/drupal7-honeypot
rpms/drupal7-job_scheduler
rpms/drupal7-mediawiki_api
rpms/drupal7-module_filter
rpms/drupal7-panels
rpms/drupal7-pathauto
rpms/drupal7-rules
rpms/drupal7-site_map
rpms/drupal7-strongarm
rpms/drupal7-theme-adaptivetheme
rpms/drupal7-token
rpms/drupal7-views_bulk_operations
rpms/drupal7-views_slideshow
rpms/drupal7-webform
rpms/drupal7-workbench
rpms/drupal7-workbench_moderation
rpms/drupal7-xmlsitemap
rpms/python-ironicclient
rpms/qtractor
rpms/rtirq
rpms/dropbear
rpms/byzanz
rpms/cairo
rpms/golang-github-elithrar-simple-scrypt
rpms/golang-github-kurin-blazer
rpms/golang-github-minio
rpms/golang-github-pkg-xattr
rpms/golang-github-restic-chunker
rpms/restic
rpms/aspell-ar
rpms/aspell-he
rpms/bidiv
rpms/hspell
rpms/hunspell-ar
rpms/python-pthreading
rpms/taarich
rpms/tex-fonts-hebrew
rpms/golang-rsc-pdf
rpms/wavbreaker
rpms/python-timeunit
rpms/python-vagrantpy
rpms/streamtuner
rpms/bird
rpms/ovirt-guest-agent
rpms/vsqlite++
rpms/dovecot-fts-xapian
rpms/VirtualGL
rpms/python-autograd
rpms/python-read-roi
rpms/byobu
rpms/kflickr
rpms/nfacct
rpms/perl-Audio-Beep
rpms/perl-CDDB
rpms/perl-Getopt-Simple
rpms/perl-NetPacket-LLC
rpms/perl-NetPacket-SpanningTree
rpms/perl-Pod-Coverage-Moose
rpms/perl-Proc-Simple
rpms/perl-XML-Parser-Lite-Tree-XPath
rpms/rust-atomic
rpms/rust-binascii
rpms/rust-cfb
rpms/rust-email-encoding
rpms/rust-infer
rpms/rust-inlinable_string
rpms/rust-multer
rpms/rust-rmpv
rpms/rust-serde_qs
rpms/rust-totp-lite
rpms/rust-ubyte
container/glusterfs
rpms/python-oslo-vmware
rpms/perl-Hash-Diff
rpms/perl-Test-Script-Run
rpms/esc
rpms/bash-completion-extras
rpms/apiextractor
rpms/appmenu-qt
rpms/arora
rpms/beefy-miracle-kde-theme
rpms/bluedevil
rpms/cagibi
rpms/colord-kde
rpms/constantine-kde-theme
rpms/dogtail
rpms/generatorrunner
rpms/goddard-kde-theme
rpms/herqq
rpms/jovie
rpms/kaccessible
rpms/kde-plasma-ihatethecashew
rpms/kio-ftps
rpms/kmag
rpms/kmousetool
rpms/kmouth
rpms/ktp-accounts-kcm
rpms/ktp-approver
rpms/ktp-auth-handler
rpms/ktp-common-internals
rpms/ktp-contact-list
rpms/ktp-filetransfer-handler
rpms/ktp-kded-integration-module
rpms/ktp-send-file
rpms/ktp-text-ui
rpms/kvkbd
rpms/laughlin-kde-theme
rpms/leonidas-kde-theme
rpms/libkcddb
rpms/libkcompactdisc
rpms/lovelock-kde-theme
rpms/pairs
rpms/plasma-widget-menubar
rpms/polkit-kde
rpms/prison
rpms/pyside-tools
rpms/python-pyside
rpms/qt-at-spi
rpms/qtsoap
rpms/shiboken
rpms/solar-kde-theme
rpms/telepathy-qt
rpms/verne-kde-theme
rpms/gogoc
rpms/lua-argparse
rpms/ibutils
rpms/keychecker
rpms/mediawiki-SpecialInterwiki
rpms/multitail
rpms/supybot-koji
rpms/trace-gui
modules/X11-base
modules/cloud-init
modules/dhcp
modules/networking-base
modules/shared-userspace
modules/storage-devices
rpms/dictd
rpms/ed
rpms/libcap
rpms/vim
rpms/cutter
rpms/groonga
rpms/groonga-normalizer-mysql
rpms/sentencepiece
rpms/salt
rpms/boinc-client
rpms/glue-validator
rpms/lcg-infosites
rpms/nagios-plugins-bdii
rpms/icaro
rpms/legofy
rpms/pg_view
rpms/zeek
rpms/gnome-video-arcade
rpms/pygtksourceview
rpms/python-etcd
rpms/libldm

Re: Orphaning all my packages

2023-10-03 Thread Carlos Rodriguez Fernandez

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-03 at 20:55 +0200, Leon Fauster via devel wrote:
> > > > Am 03.10.23 um 20:46 schrieb Sérgio Basto:
> > > > > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> > > > > > On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce <
> s...@redhat.com>
> > > > > > wrote:
> > > > > > > Additionally *all* of the code is fully available in git form
> on
> > > > > > > gitlab
> > > > > > > as part of CentOS Stream.
> > > > > >
> > > > > > We all know or should know that this is false. It's easy enough
> to
> > > > > > disprove with a counterexample:
> > > > > >
> > > > > > https://access.redhat.com/errata/RHSA-2023:1918
> > > > > >
> > > > > > Try to find the code for that
> webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in
> > > > > > CentOS Stream. It isn't there, and never will be.
> > > > > >
> > > > >
> > > > > it is here :
> > > > >
> https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9
> > > > >
> > > >
> > > >
> > > > Since June 21 the strategy changed. Such commits do not get pushed
> > > > anymore. But you are right, to prove it a different example is
> necessary ...
> > >
> > > You are wrong and have been mislead.
> > > Nothing has changed in how we develop and publish code in gitlab.
> >
> >
> > Nope, I do not argue about processes at all. Its about resulting code
> > fragments. Speak, having in gitlab version 8 of a package and in the
> > current/latest RHEL release (9.2) version 7 with backports of 8 doesn't
> > mean that the code is in gitlab. The code differs and its not
> > accessible. Thats all about.
>
> The code is still in gitlab, in most cases in directly accessible in
> individual commits. In some cases, like the one Michael mentioned,
> where a rebase landed early in the CentOS branch the code may land
> together with other changes, but it is not like it is not there.
> There are is a no regression policy in RHEL, so if CentOS is ahead it
> means it already has all of the code in question.
>
> And if there is an actual reason to need to know what exact change
> landed in RHEL there are several avenues to find out (just grab a
> developer subscription for example).
>
> I just find that this is generally just a mental exercise, but not
> something people do or need to do on a regular basis, and does not
> prevent any use, study, sharing or enjoyment of the code.
>
> Claiming the code is inaccessible sounds odd to me.
> But perhaps I am just old and remember when all you got from upstream
> was a tarball and you had to figure out what actual changes went in
> manually with diff ... no commits or commit messages and often not even
> a reasonable changelog ...
>
> Simo.
>
> --
> Simo Sorce,
> DE @ RHEL Crypto Team,
> Red Hat, Inc
>
>
>
> ___
> 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
>
___
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 all my packages

2023-10-03 Thread Carlos Rodriguez-Fernandez

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
infrastructure. It is the value of the QA done that it is no longer
available for free.

Regards,
Carlos.

On 10/3/23 14:13, Leon Fauster via devel wrote:

Am 03.10.23 um 21:29 schrieb Simo Sorce:

On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:

Am 03.10.23 um 20:46 schrieb Sérgio Basto:

On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:

On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
wrote:

Additionally *all* of the code is fully available in git form on
gitlab
as part of CentOS Stream.

We all know or should know that this is false. It's easy enough to
disprove with a counterexample:

https://access.redhat.com/errata/RHSA-2023:1918

Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in
CentOS Stream. It isn't there, and never will be.

it is here :
https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9

Since June 21 the strategy changed. Such commits do not get pushed
anymore. But you are right, to prove it a different example is
necessary ...

You are wrong and have been mislead.
Nothing has changed in how we develop and publish code in gitlab.

Nope, I do not argue about processes at all. Its about resulting code
fragments. Speak, having in gitlab version 8 of a package and in the
current/latest RHEL release (9.2) version 7 with backports of 8 doesn't
mean that the code is in gitlab. The code differs and its not
accessible. Thats all about.

OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature
___
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: Making sense of golang packaging guidelines

2023-07-20 Thread Carlos Rodriguez Fernandez

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 Rodriguez Fernandez <
> carlosrodrifernan...@gmail.com> wrote:
> > 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/
> > <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 have shared runtime objects, and devel packages
> provide the
> > interface to link to them when necessary; however golang compiles it all
> statically. It is
> > very easy to bring all the dependencies locally for compilation directly
> from git repos and
> > then nothing is necessary at runtime.
> >
> > Creating rpm packages for each golang dependency seems counterproductive
> as it adds an
> > additional burden to maintain without the benefits of shared runtime
> objects.
> >
> > I have the feeling I am missing something. What is the benefit of having
> each golang build
> > dependency as rpms?
> > Is it a requirement for golang programs rpm contributions or it is
> optional? (e.g.
> > prometheus in EPEL9 does not follow the deps handling guidelines but not
> sure if it is a
> > tech debt or an option).
> >
> >
> > Thank you,
> > Carlos
> >
>
> We need to build into Koji, there is no "local build". As such we have two
> options :
>  - bundle the dependencies in the package
>  - package all the libraries separately
>
> The Fedora guidelines is to package library separately, per
> https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ :
>
>
>
> All packages whose upstreams allow them to be built against system
> libraries must be built against system libraries.
>
> All packages whose upstreams have no mechanism to build against system
> libraries must be contacted publicly about a path to supporting system
> libraries. If upstream refuses, this must be recorded in the spec file
> using a persistent mechanism to be clarified in the packaging guidelines.
>
> All packages whose upstreams have no mechanism to build against system
> libraries may opt to carry bundled libraries, but if they do, they must
> include Provides: bundled() = in their RPM spec file.
>
>
> This policy only applies to Fedora. In EPEL we bundle because we don't
> have our macros and the Go ecosystem is not bootstrapped.
>
> Best regards,
>
> Robert-André
> ___
> 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
>
___
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

Making sense of golang packaging guidelines

2023-07-20 Thread Carlos Rodriguez Fernandez

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 have shared runtime objects, and devel packages
provide the interface to link to them when necessary; however golang
compiles it all statically. It is very easy to bring all the dependencies
locally for compilation directly from git repos and then nothing is
necessary at runtime.

Creating rpm packages for each golang dependency seems counterproductive as
it adds an additional burden to maintain without the benefits of shared
runtime objects.

I have the feeling I am missing something. What is the benefit of having
each golang build dependency as rpms?
Is it a requirement for golang programs rpm contributions or it is
optional? (e.g. prometheus in EPEL9 does not follow the deps handling
guidelines but not sure if it is a tech debt or an option).


Thank you,
Carlos
___
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?]

2023-07-14 Thread Carlos Rodriguez-Fernandez




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) compatible*


Imagine Red Hat shutting down CentOS Stream in a year or two just 
because they [Alma, etc.] started doing rebuilds. :-D



That would be epic, LOL.


OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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?]

2023-07-14 Thread Carlos Rodriguez-Fernandez


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 Binary Interface (ABI) compatible*


We will also start asking anyone who reports bugs in AlmaLinux OS to 
attempt to test and replicate the problem in CentOS Stream as well, so 
we can focus our energy on correcting it in the right place.


While all of these changes open up a lot of opportunities, we want to be 
clear about the fact that we are still dedicated to being good open 
source citizens. We’ll continue to contribute upstream in Fedora and 
CentOS Stream and to the greater Enterprise Linux ecosystem, just as we 
have been doing since our inception, and we invite our community to do 
the same!





On 7/12/23 15:28, Leslie Satenstein via devel wrote:
SUSE has also jumped in to say they will provide an alternative, but 
compatible Linux to RH.




Leslie Satenstein



On Tuesday, July 11, 2023 at 06:49:38 a.m. GMT-4, Kevin Kofler via devel 
 wrote:



Oracle has (finally – the community projects Rocky and Alma were much
quicker to react) made an announcement about the situation:
https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/ 


         Kevin Kofler
___
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 



___
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


OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-07-02 Thread Carlos Rodriguez-Fernandez


Hi Michael,

We have been told repeatedly that "the source is there" in CentOS 
stream. I can see the scenario that RH branches from CentOS stream to 
create a new minor release, and during QA, a bug is discovered and a 
patch is backported (or created) to fix it internally in your minor 
release branch. However, if that bug wants to be addressed also in the 
next minor release, it will need to appear in the CentOS stream at some 
point, whether via a patch or an entire source version bump.


If that's not the case, then RH is having some long living parallel git 
repo which 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 forward, you will see those patches contributions going into
Centos stream first, and they will be accepted by RH engineers, and then
they will end up in CentOS Stream distro first, and finally in RHEL.


Just for the record: no, you'll never see updates like those in CentOS 
Stream because that was a stable branch update after RHEL had already 
branched from CentOS Stream. Those patches will never appear in CentOS 
Stream because I do not push them there.


Michael

___
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


OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-07-01 Thread Carlos Rodriguez-Fernandez




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 feel forced to use CentOS
Stream. While at the same time, distributions of my choice Fedora,
Scientific Linux, CentOS Linux, Rocky Linux, and AlmaLinux, are
consequently taken down, to a moment that I'm not sure whenever RHEL is
still an open-source software.


It is still as opensource as it is Ubuntu and SUSE. There are no clones 
of Ubuntu LTS with 10 years lifecycle, nor of SUSE Enterprise with their 
10+ lifecyle.




Most likely, I'm too paranoid, but I'm
afraid that if Red Hat successfully kills RHEL downstream projects, bad
things will start to happen to CentOS Stream as well.


I'm afraid that could be the case too. This move will cool down the EL 
community significantly. I'm concerned of the future of EPEL itself. I 
wish RedHat would reduce their prices significantly for wider adoption, 
or just give the first 5 years for free as Ubuntu does.


Regards,
Carlos.


OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-30 Thread Carlos Rodriguez-Fernandez

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 modify the patches themselves to appears as coming from them or 
RedHat employees.


Going forward, you will see those patches contributions going into 
Centos stream first, and they will be accepted by RH engineers, and then 
they will end up in CentOS Stream distro first, and finally in RHEL.


That's how normally distros operate when they do backporting.


On 6/30/23 08:15, Leon Fauster via devel wrote:


Am 30.06.23 um 15:41 schrieb Leslie Satenstein via devel:


    What should I do, if the person I gave the software to, removes my
    copyright, rebrands the software and sells my software as their own?
    Is it right? And when I release a bug fix, they take it, insert the
    fix into the rebranded copy they are selling, and they quietly say,
    "Screw You, Leslie".


Ask yourself; how does open source methodology works?

Just using your words: Apple Inc. releases a bug fix, RedHat takes it,
insert it into the rebranded copy (RHEL) they are selling ...

https://git.centos.org/rpms/webkit2gtk3/c/f1679e95706409206b768d4f0a03563066c52bda?branch=c8




OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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: Red Hat & Fedora -- largely stepping out of this ecosystem

2023-06-27 Thread Carlos Rodriguez-Fernandez

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
OpenSUSE where there is continuous development, and then if you want the
full 10 years (with the additional 5 years of maintenance), you would
choose SUSE Enterprise and paid the subscription fee.

Debian provides only 5 years cycle, and no support after that at all.

Red Hat is stopping the free 10 years cycle support provided by clones,
and going the same route other distros are already in. The difference
with RedHat is the fact that their free 5 years cycle distro (centos
stream) is a tiny bit ahead of their subscription 10 years one (rhel). I
personally don't see it as a deal breaker difference.

Am I missing something about the other distros?

I'm using CentOS Stream 9 hardened in production-level servers, and also
in personal servers. The tooling, the community maturity, and the
SELinux support of Enterprise Linux is much better than the alternative
in my opinion.

I use Fedora for my personal workstation and my kid's computer, and what
I love the most about Fedora is how it has become the vanguard in
innovation among Linux distros.

RedHat is just being a for-profit company, aligning itself with the rest
of Linux distros supported by a company. The only main difference is
that their "free tier" is slightly ahead of their Enterprise
subscription one. It depends how big of a deal that really becomes going
forward, but so far I don't see indications that it will be a big deal.
They have broken both in the past, the free and the paid.

Their contributions to opensource won't stop. The innovation in Fedora
won't stop either. Jeff, I hope you reconsider your decision.

Regards,
Carlos R.F.

On 6/27/23 07:40, Peter Boy wrote:

Thanks for your writing. A well-balanced and very thoughtful and considered
opinion. But your final decision seems to me rather a short-coming.

Am 27.06.2023 um 00:47 schrieb Jeff Law :

...

What Red Hat has done recently is depressing, but not a huge surprise to me. Red Hat struggled
repeatedly with how to deal with "the clones". The core idea I always came back to in
those discussions was that the value isn't in the bits, but in the stability, services and
ecosystem Red Hat enables around the bits. Arguments for protecting the bits were met with
something like "if that's what we need to do to be successful, then we're failing to provide
real value".

At some point in the last 20 years (I forget exactly when) Red Hat was looking
to codify its values. Naturally the topic of open source came up during those
discussions. When open source didn't make the cut, one could say the writing
was on the wall -- open source was a means to an end. In my mind that opened
the door for numerous changes we've seen in subsequent years.

One could see signs of where this was going with the adjustments that were made
to the exposed RHEL kernel sources some time ago. Then the dissolution of
CentOS a couple years back and most recently with the lockdown of the RHEL
sources.

What Red Hat has done may be technically legal and perhaps good for its
business. However, to me it's ethically unconscionable. Those who know me
know I'm not an zealot, but I do have a baseline set of ethical values and Red
Hat crossed that line.

I think there is a difference regarding the clones.

When Red Hat cancelled the academic licenses I switched all the servers I was responsible
for to Scientific Linux, one of the clones. As a public funded University we simply
couldn’t afford the new prices. And there was no such thing as "customers" for
us to pass on higher costs to. The results of our work are available to the company free
of charge.

But cases like OracleLinux, where a commercial company takes another company's
work and uses it to throw a competing commercial product on the market, are
something else, entirely. And they are to be evaluated differently beyond legal
licensing issues.

And as much as I disapprove of Red Hat's decisions that led to the end of
ScientificLinux, at the same time I can kind of understand it. But more
differentiation of such circumstances would have been better.

Perhaps it is a quandary, unsolvable without compromise.

...

I've been a Fedora user since before FC1. I run Fedora on my laptop. When I
need a docker image for something, I start with a Fedora image. When I need to
spin up a server (say to run the GCC CI/CD system) I load it with Fedora.
It's an ecosystem I'm technically comfortable in and easiest for me to utilize.

That will change across the board this summer. That's a bit hard for me to
swallow, but I can't get past that association we built between Red Hat and
Fedora and Red Hat's recent actions.

I'll still have to

37 matches

Mail list logo