Re: Three steps we could take to make supply chain attacks a bit harder
Am 17.04.24 um 23:34 schrieb Kevin Kofler via devel: And in my view, the fact that, in those implementations, there is no Treacherous Computing hardware preventing me from doing what I want with my own private key (e.g., just copying the same key to all my devices, as I can also do with TOTP) is actually a feature, even if it goes against the "security" model. The fact that you can share the keys is actually part of the design and wanted. Apple for exmaple has (or wants to) implement easy sharing of passkeys via AirDrop. Regards Kilian Hanich -- ___ 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?
Am 08.04.24 um 14:55 schrieb Emmanuel Seyman: Well, you and Kevin see "salami tactics" (whatever that may be), FTR, I have no idea what "salami tactics" is. Since apperently multiple people don't know the term: https://en.wikipedia.org/wiki/Salami_slicing_tactics Regards Kilian -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 04.04.24 um 03:00 schrieb Gordon Messmer: I think this gets to the heart of the issue. If we set aside subjective arguments about which desktop is better or more popular, only one of these desktops allows Fedora to publish a stable operating system which is a coherent whole, because only one of them has a release cycle that aligns with Fedora's. The other desktop's release cycle does not align, which means that a significant component of the system rebases in the middle of a release, which undermines the fundamental concept of a stable release. About the release cycle: After the initial release of Plasma 6 when dust has mostly settled down (approx. 2 point releases), they want to switch over to a release cycle which would align (which is likely also the reason why F42 was choosen in this proposal). Kilian -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 04.04.24 um 01:46 schrieb Sam Varshavchik: This is not going to happen. There's going to be someone else, sitting next to them, who will be teaching the new user how to use a computer. And that someone will /also/ be familiar with traditional desktop concepts and paradigms. They, like the new user, will also expect to have a traditional desktop in front of them, that works like a traditional desktop. Sure, but in a lot of cases that other person is a teacher, with a lot of other children needing attention too. That means you have one experience user vs (depending on country) 10 to 50 new users. Kilian -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 04.04.24 um 01:03 schrieb Kevin Kofler via devel: You make a good point there. The thing is, GNOME tries really hard to design for new users, whom they define as a user who has never before used a computer. Such users are basically on the edge of extinction. A paradigm that works great for someone seeing a computer for the first time in their life does not necessarily work all that great for someone trained to use different paradigms used in the operating system(s) they have used for decades. Most new Desktop users these days have prior experience of using a smartphone or maybe even a tablet. That funnily enough has the side effect that a lot of them try to touch the screen when they use a Desktop for the first time. As you can maybe imagine, these people are very young. Now, some people would argue that Gnome is a good design for a DE for people expecting something like a smartphone UI but made good for a Desktop, some people say the opposite. Personally I think it's a tradeoff. There are equally as many (and strong) arguments for and against it. Regards Kilian Hanich -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Am 03.04.24 um 01:48 schrieb Kevin Fenzi: On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote: Alright, so a substantial amount of information changed since the original submission of the change proposal. We aren't necessarily thinking of demoting Gnome. The overall spirit of the CP is that we think KDE, and to some extent the other spins too, need a bit more visibility on the website. At the very least, Gnome and KDE should be up front on the frontpage. So, I am far from a web designer, but if you aren't a Linux savvy person and just decided to try out this Fedora thing because you heard it was nice and you go to download it and get: Quite frankly, considering the goals and the philosophy of Fedora (always trying to push for new stuff even if it isn't fully ready yet), I would argue that Fedora isn't for Linux savvy people. Kilian -- ___ 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
Am 02.04.24 um 10:22 schrieb Florian Weimer:
- Can some wrappers be developed to make it both easier and safer?
GCC already provides function multi-versioning/target clones as a
higher-level interface.
Also, upstreams should by default properly mark their stuffs with
restrictive visibilities.
While we are a few decades to change the defaults, that doesn't mean
that one can't choose the better option. So, by default one should
choose -fvisibility=hidden and mark the public API with
__attribute__((visibility("protected"))) or, if they really want a
function to be interpositionable (by e.g. LD_PRELOAD) as
__attribute__((visibility("default"))).
As a side effect, if you ever want your library be usable on Windows,
you need to do that anyway since hidden is the default there and your
public API must be marked explicitly. (Also, Windows doesn't support
interposition and also doesn't support cyclic library dependencies
without complicated hacks. So yeah, Windows kinda has the better
defaults here.)
Some newer languages do that anyway already, but we obviously can't just
change it for C and C++ projects.
But depending on the architecture this may not necessarily be possible.
So yeah, only upstream can do that, not us.
Regards
Kilian Hanich
--
___
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
Am 31.03.24 um 23:02 schrieb Scott Schmit: On Sun, Mar 31, 2024 at 04:09:36PM -0400, Ben Beasley wrote: On 3/31/24 2:12 PM, Kevin Kofler via devel wrote: 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). While it’s technically correct that deleting tests would have disrupted this specific attack, a policy of deleting and and never running upstream test code would have prevented me from finding and helping upstreams fix dozens and dozens of bugs due to accidentally faulty assumptions that turned out to be violated on different architectures, in different system environments, or with various allegedly-compatible dependency versions. There are even GCC bugs (miscompilations, not only failures to compile) that were discovered and fixed only because packages I maintain were running upstream unit and integration tests. Frankly, “testing the packages we ship, as built in our distribution, is actually bad” seems like a pretty strange and extreme conclusion to draw from all of this. Deleting the tests makes no sense to me either, but it seems like a mechanism that ensures the test code can't change the build outputs (or a mechanism to detect that it's happened and abort the build) would allow upstream tests to be run without compromising the integrity of the build itself. It would prevent the attack from being hidden in the tests, but not in any other part of the build. Also, I have seen build setups which encode the status of tests in the eventual binary and as such info page or integrated bug report generators. Often because some distros sometimes turned them off or ships software even with failed tests and thus pushing that headache to upstream. Regards Kilian Hanich -- ___ 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
Am 31.03.24 um 21:19 schrieb Simon de Vlieger: I don't quite agree with you. Two factor authentication whether an actual second factor device or not does prevent credential stuffing which is a common attack method that is easy to perform. It is when people take databases of previously leaked passwords and try them on other accounts that belong to the same person. Since two factors are generally unique per login situation they can't be stuffed in the same way. Of course there are many things two factor does not protect against. 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). This can also lead to a pretty interesting "circle" of 2FA where for example email a is the 2FA address for email b and email b is the 2FA address for email a. If it's the only option it can also lead to a chicken and egg problem for young people who want to create e.g. their first email account. But this paragraph is besides the point. So, sure, 2FA would prevent people from just trying out leaked passwords. But an attack like this would not be a "spray and pray" attack, but it would be a targeted one. This means that the acceptable effort from the attacker would be quite a bit higher. 2FA would prevent script kiddies and "spray and pray"-style attacks from being successful. But more? Doubtful. Regards Kilian Hanich -- ___ 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
Am 30.03.24 um 20:11 schrieb Kevin Kofler via devel: Or better: Do not execute tests to begin with! rm -rf test in %prep and NEVER run tests during builds. Even when the tests are all legitimate, all it does is slow down the build (e.g., compare glibc build times without and with tests) and every so often break it because the test, not the software, is broken. And a claimed "test file" is what allowed the payload to be snuck in here. Unit tests are something for upstream developers. They should NEVER be run in a distribution build. As a developer I need to say: If your build also runs your tests implicitly even if you just want to make a normal build of your software, your build setup is broken. That should just not happen. But "rm -rf test" or something like that may not be possible. Quite some projects (or just straight up languages) these days have their tests in the same file as the code they test. Kilian Hanich -- ___ 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
Am 30.03.24 um 15:44 schrieb Zbigniew Jędrzejewski-Szmek: Meson outclasses CMake in functionality, clarity, and brevity. I doesn't make sense to consider switching to CMake at this point. While I do agree on clarity and brevity, I don't on functionality. Meson doesn't allow you do create your own functions. While one should try to avoid them in build systems, there are cases where you need them. I work on a project where they are needed, but it also wouldn't make sense to upstream it because it's too project specific, and creating a loop out of every call like Meson's FAQ recommends (https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros) would create one heck of spagetthi code. So yeah, there are edge cases where I would recommend CMake over Meson purely without looking at the rest of the ecosystem. Another is ofc that a quite big chunk of the C and C++ ecosystem uses CMake and integration between build systems kinda sucks (but the CMake developers try to work on making it better by working together with other projects). But I don't think this is the right place to talk about which build system to switch to FOR OTHER PROJECTS. (But if we are at it, ever looked at Zig as a buildsystem for a C or C++ project? I know some companies which do this at this point.) Sincerely Kilian Hanich -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Am 10.02.24 um 09:47 schrieb Neal Gompa: Technically, turning off display sync completely is quite difficult right now since the actual driver stack in Linux underneath everything (both Wayland and X11) uses implicit sync right now (Linux kernel drivers, Mesa drivers, etc.). Interesting considering that I once read (but haven't fact check) that the Vulkan spec explicitly requires explicit sync instead of implicit, even if you for parts of it. That said, there's a move to support explicit sync in Wayland[1], and the first steps of that for KWin have been written up as a merge request[2]. Once there's an agreed upon mechanism for explicit sync, it would be possible to support something like that. [1]:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 [2]:https://invent.kde.org/plasma/kwin/-/merge_requests/4800 Interesting read. I will just hope that this won't be something which ends up in "noone actually still looks at it"-land as some things sometimes end up in because people focused on different things and then forgot about it (well, kind natural for volunteer projects I guess). Kilian Hanich -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Am 09.02.24 um 18:28 schrieb Neal Gompa: On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken wrote: On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote: On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken wrote: On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote: I am not gonna reply to all of that because all we are doing at this point is repeating the same thing. But we are NOT stopping you from using x11. You can either build it yourself and put it on a copr (it’s not like neal is using voodoo in his copr), use the copr we provide or … This is extremely hostile towards new people trying linux for the very first time, asking them to add a copr repo if they have problems with wayland to try X11, its unlikely they ever heard this stuff before. Most likely they are trying out Fedora on a live media. And they're not going to get an X11 experience on live media even now. Wayland has been used for all environment modes since Fedora 36. I am aware if this. So you are saying that its perfectly fine that someone new to linux boot into a desktop that microstutters when they move windows around? No, it's not fine. Just like it's not fine to get random tear/corruption snow when moving things around or opening windows on X11. The difference is that we can actually do something about those issues with Plasma Wayland when people report them. *Tons* of these kinds of issues were fixed over the past 3 years, and Plasma 6 brings a huge upgrade around this stuff too. And the whole graphics pipeline is fully under the control of KDE Plasma, so we can do things we've never done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional scaling, and so much more. We can do things that even other Wayland desktops can't do because our architecture is flexible enough to do it. With Plasma X11, our necks are hanging to the dying albatross that is the X server and our hands are tied behind our backs when we want to actually do something to improve the experience. These are not issues with Plasma Wayland. Because Plasma Wayland... is just KDE Plasma. Quite a bit of topic from my part, but is your pipeline for Wayland flexible enough to turn off any kind of display sync (even in windowed mode) if the user wants that? Sure, it has its downside (e.g. tearing can happen), but I rather have that than the added latency (even if very minimal) of such a sync (and yes, that includes VRR which has a considerable smaller one than normal V-SYNC). -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
Am 01.02.24 um 17:44 schrieb Neal Gompa: That is not necessarily true. For your example about window placement, there is this:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 Am 01.02.24 um 17:46 schrieb Neal Gompa: Sorry, I meant to point to this as well: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 These two are imo more example which try to prove Falco's point because of: 1. How long this is going on. 2. How many attempts this person made so far. 3. How much some of the maintainers don't want *something* like this (if you go and read through the thread). But yeah, I hope we get something at some point which isn't as stupidly complicated like needing to generate and register transient desktop files to set dynamic window icons (you can't always know them in advance if you have a plugin based application; or when multiple windows should have different ones). I know that there is also a proposal (after multiple failed tries) in discussion, but there are even more maintainers who don't want that. (And I am kinda afraid that if it comes around, it will be a non-flatpak thing, which would be sad considering that I like Flatpak and immutable distros, so I hope that I could at least turn that "protection" off). But well, Let's hope for the best. Kilian Hanich -- ___ 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
