Fedora 38 gaat standaard toegang geven tot ongefilterd Flathub-softwarecenter

De ontwikkelaars achter Fedora gaan volledige toegang tot Flathub mogelijk maken. Momenteel kunnen gebruikers een beperkte hoeveelheid Flathub-apps gebruiken, maar vanaf versie 38 krijgen ze toegang tot een ongefilterde lijst.

Het Fedora Engineering and Steering Committee heeft definitief akkoord gegeven op die wijziging. Dat gebeurt vanaf Fedora 38, dat op 18 april uitkomt. In die versie krijgen gebruikers toegang tot een allowlist waarin geen beperkingen meer zijn opgelegd aan de apps die in het softwarecenter worden aangeboden.

Sinds versie 35, die uitkwam in 2021, kunnen Fedora-gebruikers appwinkel Flathub configureren via het eerste Gnome-keuzescherm dat ze bij installatie te zien krijgen. Dat softwarecenter wordt echter gefilterd door een allowlist. Daardoor is maar een beperkt aantal apps beschikbaar.

Het was altijd wel mogelijk om de ongefilterde versie van Flathub te gebruiken om zo de meer dan 2000 apps te krijgen, maar gebruikers moesten Flathub daarvoor zelf herconfigureren via de commandline. Dat hoeft vanaf Fedora 38 niet meer. De ontwikkelaars schrijven niet waarom de regels worden teruggedraaid. In Fedora 35 werd de allowlist toegevoegd om meer controle te kunnen houden over de apps die in de winkel staan.

Door Tijs Hofmans

Nieuwscoördinator

07-02-2023 • 13:20

27 Linkedin

Submitter: TheVivaldi

Reacties (27)

27
27
21
4
0
4
Wijzig sortering
Flathub (en Snapcraft) hebben eigenlijk alleen voordelen voor (1) ontwikkelaars die Linux-ondersteuning als een nagedachte beschouwen, en (2) commerciële closed source software. Als de software open source was, dan was er immers altijd wel een groep vrijwilligers te vinden om het zelf in de juiste packages te compileren. Denk aan EPEL voor RHEL-derivatives of GetDeb voor Ubuntu/Debian.

Nadelen (van ongefilterde toegang) zijn dat je niet kan controleren welke code of malware je draait, en dat je moeilijker kan afdwingen dat je alleen iets installeert van een bron die je vertrouwt. Iemand met veiligheidszorgen had er zelfs een URL voor geregistreerd.

Als je goede Linuxsoftware schrijft, dan is het allemaal niet zo'n probleem. Compositing- en 3d software Blender bijvoorbeeld, ze distribueren één binary, en die werkt op vrijwel alle Linux distro's.
Ik ben al een tijdje uit de linux omgeving weg, maar wat is de toegevoegde waarde van zo’n appstore? Ik kan me eigenlijk niet herinneren dat ik ooit iets anders nodig had dan (meestal zelfs de standaard) repositories in Linux. Is er iets significant gewijzigd dan (of is er een andere reden die ik nu even niet zie)?
Veel software wordt alleen voor bepaalde distro's gemaakt (doorgaans Ubuntu, en dan óf de huidige LTS óf juist de vorige). Pakketten maken voor Fedora/OpenSUSE/Arch/kies een smaak wordt vaak niet gedaan.

Je kunt de binaries downloaden en uitvoeren maar dat gaat goed totdat je distro een nieuwere/oudere versie van een library gebruikt. Handmatig met versies klooien is eigenlijk niet te doen zonder nog veel meer gedoe.

Met Flatpak en vrienden kun je alle afhankelijkheden in één pakket gooien. Zo werkt je applicatie op bijna iedere Linuxdistributie die je kunt bedenken. Je ziet daarom vaak software in een paar versies aangeboden worden: via een Ubuntu-repository, misschien een Fedora-repository, en in Flatpak/Snap/AppImage-formaat voor de overige distro's. Vaak zet iemand op de Arch User Repository nog een scriptje op om je applicatie voor Arch-mensen te downloaden te maken, maar dat is meestal onofficieel en/of zonder ondersteuning of garantie voor updates.

Daarnaast hebben Flatpak/Snap nog een veiligheidsvoordeel (afhankelijk van je bedreigingsmodel), ze worden namelijk standaard gesandboxed zoals bijvoorbeeld ook mobiele apps, met de mogelijkheid om realtime toegang tot bepaalde (systeem-)mappen te ontzeggen met de juiste GUI/command line utilities. Sommige mensen zijn deze features liever kwijt dan rijk en je kunt ze beperken of uitzetten, maar voor mensen die de veiligheid van mobiele apps gewend zijn, is het een uitkomst.
Een ander voordeel van Flatpak is ook dat applicaties nieuwer kunnen zijn dan die in de repositories.

Ik gebruik bijvoorbeeld Debian Stable op mijn desktop, omdat ik er een grafhekel aan heb als plotseling dingen in mijn werkomgeving veranderen (vooral als dat de desktop-omgeving is). Ik wil dat alles hetzelfde blijft totdat ik zelf besluit om te upgraden.

Echter, er zijn grote applicaties waarvan ik WEL altijd de laatste versie wil hebben:
- Visual Studio Code
- Lutris
- LibreOffice
- GIMP
- DarkTable
- Calibre

Als die niet een officiële Debian Stable compatible repostiry aanbieden (zoals VS Code en Lutris bijvoorbeeld wel doen), dan gebruik ik voor die applicaties een Flatpak. Alle andere applicaties waarvan ik niet zo gebrand ben op de laatste versie pak ik dan gewoon uit de Debian repo. Ik vind het bijvoorbeeld niet belangrijk om de allerlaatste versie van KWrite of KCalculator te hebben, en zolang de webserver (Apache / nginx) ondersteund wordt, is die ook prima totdat de volgende versie van de distro langskomt.

Dan heb je nog de vreemde eenden in de bijt, zoals Rust (programmeertaal): de versie in de Debian Bookworm is 1.48, maar de huidige versie is 1.67. Zelfs Bookworm, die pas over 5-6 maanden uitkomt, ligt al achter met versie 1.63, en van Rust komt elke 6 weken een nieuwe versie uit. Omdat het een jonge programmeertaal is die nog aardig in ontwikkeling is (al begint het wel wat af te remmen) wil ik daarvan graag de laatste versie hebben. Die kan ik niet krijgen via Debian of Flatpak, dus deze installeer ik als een van de weinigen (enige, op dit moment) direct vanaf de officiële site. Die levert je dan "rustup" op: Rust's package manager, die alle Rust-spul lokaal in jouw eigen /home installeert.
Voor een groot deel eens, ik zie het besturingssysteem los van de end-user applicaties. Het OS moet stabiel en veilig zijn dat niet te veel verandert. Van de end-user applicaties heb ik dan graag de laatste versie van iets zoals Darktable... met flatpaks kan je dat mooi scheiden.

Let wel, flatpaks zijn wel een heel pak groter dan de repo versies.... onlangs geschrokken hoe groot verschil wel kan zijn. Nuja, flatpaks zouden linux wereld wel eens een serieuze boost kunnen geven...
Voor een groot deel eens, ik zie het besturingssysteem los van de end-user applicaties.
Velen in de Linux-wereld zijn het daar nog steeds niet mee eens, omdat je dan libraries van verschillende versies en/of meerdere keren dezelfde library op de computer moet toestaan. Men wil liever super-nerdy super-klein zijn met alles. OK, ik snap dat er voordelen zijn aan "één library, één keer, van één versie", maar zo verwikkel je wel het hele OS en al je applicaties met elkaar. Dan kun je makkelijk in een upgrade-ketting terecht komen: om één app te updaten moet je een library updaten, waardoor je alle apps die daarvan gebruik maken ook weer moet updaten, etc...
Het OS moet stabiel en veilig zijn dat niet te veel verandert. Van de end-user applicaties heb ik dan graag de laatste versie van iets zoals Darktable... met flatpaks kan je dat mooi scheiden.
Het is een van de redenen waarom ik uiteindelijk full-time over ben kunnen stappen op Linux. Van sommige software vind ik het niet erg als de versie 2 jaar achter ligt. Ik heb een paar programma's in gebruik die ondertussen bijna 15 jaar oud zijn, die draaien in Wine, omdat er geen goede vervangers zijn onder Linux, en nieuwere versies me nooit hebben bevallen vanwege enkel het wijzigen van de GUI en toevoegen van online functionaliteit die ik niet gebruik. Andere programma's wil ik wel graag de laatste versie van hebben, en totdat FlatPak een ding werd, kon dat niet; behalve met een rolling distro, en dat wil ik ook weer niet.
Let wel, flatpaks zijn wel een heel pak groter dan de repo versies.... onlangs geschrokken hoe groot verschil wel kan zijn. Nuja, flatpaks zouden linux wereld wel eens een serieuze boost kunnen geven...
Opslag en geheugen is hetgeen ik me nog het minste zorgen om maak. Ik heb al 32 GB RAM en 4TB opslag sinds 2016, en mijn volgende computer gaat hetzelfde krijgen... maar dan met de optie om uit te breiden naar 64GB en 8+ TB aan SSD's, laat staan eventuele HDD's die ik er nog in steek voor lompe data-opslag...

"Ja maar, al die mensen die nog 15 jaar oude computers gebruiken dan..." Nou, dan gebruiken die geen FlatPaks en werken ze op de oude enkel-repo manier. Kan ook nog gewoon; in elk geval met de meeste distributies.
Een nadeel is dan weer dat die dependencies geen security fixes krijgen, en je, afhankelijk van de snap/flatpak/... builder, misschien met outdated libraries en dus security risks zit, zelfs bij de laatste versie van de hoofdapplicatie.

Ik vind het een noemenswaardige spijtige evolutierichting voor het Linux distributielandschap, hoewel het voor one-offs wel handig is (ik heb het bvb gebruikt voor een Tiberian Sun snap, die onder mijn system Wine last had van een of ander issue waar ik niet rond geraakte; maar die had dus een heel oude Wine versie met al zijn dependencies ingebakken, eigenlijk een security nightmare).
Een nadeel is dan weer dat die dependencies geen security fixes krijgen, en je, afhankelijk van de snap/flatpak/... builder, misschien met outdated libraries en dus security risks zit, zelfs bij de laatste versie van de hoofdapplicatie.
Dit argument snap ik nooit zo goed. Zou er daadwerkelijk onder Linux een mogelijkheid zijn om een specifieke verouderde library in een Flatpak voor een aanval te gebruiken? Het enige dat ik me kan voorstellen is een browser die code uitvoert en misbruikt wordt om op de een of andere manier uit zijn Flatpak-omgeving te breken en schade aan te richten. Ik kan me bijna niet voorstellen dat er malware bestaat die een (oude) Flatpak-versie van GIMP probeert aan te vallen vanuit de Flatpak van de browser of iets dergelijks. (Zou niet eens moeten kunnen, want Flatpaks zijn voor zover ik weet sandboxed; de app zou alleen zijn eigen omgeving moeten kunnen zien.)

Qua browser draai ik Firefox ESR op Debian, mede omdat de Flatpak-versie niet goed werkt met het ingestelde KDE-thema. (Misschien moet ik die nog eens proberen.) Zelfde voor Thunderbird.
Niet alle exploits zijn bedoeld om je systeem over te nemen.
Neem een verouderde (dependency van een) browser, waardoor er via een bug een of andere mottige JavaScript kan uitgevoerd worden die dan je bankgegevens kaapt. Of je redirect naar een schadelijke we site en het van je kan verbergen omdat die snap verouderde certificaten gebruikt, of een verouderde encryptie toelaat.

Dat dat ding in een sandbox draait is trouwens helemaal niet zaligmakend, hoewel ik daar de technische details niet van ken. Zoals ik al zei gaat het me dan vooral om misleiding en andere problemen binnen de snap applicatie die mogelijk gemaakt wordt door de ongepatchte kwetsbaarheid.
Nuja, zo aan de andere kant is ongeveer iedere Windows applicatie hier kwetsbaar aan, aangezien die heel vaak een hele resem aan libraries meezeulen, en die ook niet allemaal regelmatig geüpdatet worden…
Qua desktop software zal het risico wel meevallen. Qua server software begrijp ik het wel. Als jij een website host die ergens in een library log4j gebruikt dan ben je afhankelijk van de ontwikkelaar om eventuele problemen te fixen. Als je OS libraries gebruikt kan je het zelf fixen.

Niet helemaal natuurlijk want je kan zo'n pakketje manipuleren mja dat heeft bijwerkingen en is op schaal niet echt beheersbaar

[Reactie gewijzigd door Mellow Jack op 7 februari 2023 17:20]

Afgelopen FOSDEM was er ook een mooie talk over het containerizen van applicaties.

Zie bijgevoegde link bijvoorbeeld:
https://youtu.be/4WuYGcs0t6I

Samenvatting:
In 2017 I spoke at FOSDEM and told everyone about how Containerised App technologies like AppImage, Snap, and Flatpak were all terrible and posed the question "What could go wrong?" if we introduced them. Now, in 2023, I am building a Desktop Linux distribution that only uses Flatpaks for it's Apps, so obviously, something went horrifically wrong, but not with Flatpaks.

This talk revisits some of my arguments from 2017, and discuss how the Flatpak team in particular embraced and addressed those concerns. It also revisits the arguments advocating for traditional packaging and how they increasingly fall down when compared to the Flatpak way of doing things. That said, this session attempts to present a balanced argument, and highlight the risks and responsibilities this approach requires and how some of the containerised app technologies still fail to meet those challenges.

As a conclusion, this session presents a vision for more distribution and packaging projects to follow, possibly narrowing the scope of their efforts to better collaborate and embrace the potential on this new way of getting FOSS software in the hands of users.
Heeft men met de flatpak niet in feite het MSI-bestand/Windows Installer opnieuw uitgevonden?
Nee want een Flatpak komt uit een repo bijvoorbeeld Flathub en msi bestanden zijn gewoon losse bestanden die je van random software makers website kan downloaden en Flatpaks zijn containerized.

[Reactie gewijzigd door Hydranet op 8 februari 2023 07:58]

Eerder appImage onder Mac OS.
Sommige packages bijvoorbeeld Spotify zijn alleen beschikbaar voor Ubuntu, dus voor dat soort gevallen is het best handig om wel op die manier te kunnen installeren en sommige Flatpaks worden beter bij gehouden als sommige packages uit rpmfusion. Waar ben jij dan naar overstapt?
Offtopic: Windows O-) In de jaren negentig/begin 2000 veel met Linux gedaan maar na mijn studententijd verdween de goesting om nog Linux te booten (had altijd al dual boot voor gamen, en ben in de tijd ook steeds meer met Adobe gaan doen)

On-topic: dat sandboxen is nog wel interessant. Ik wist niet dat packages niet meer voor de meerderheid van de distro’s gemaakt werden, dat is wel jammer eigenlijk…
simpelweg meer packages, Spotify, Skype, Teams, Whatsapp, .. Zelf gebruik ik voornamelijk snap. Enige irritante is dat de opstarttijd langer is, omdat 't in een container draait. Daarom is m'n voorkeur de standaard repository van de distro dat ik gebruik (ubuntu).
Het distribueren van een applicatie voor Linux had vroeger veel haken en ogen. Dit waren de meest voorkomende opties:
  • Broncode aanbieden en gebruikers het zelf laten compileren - niet user-friendly, niet bruikbaar voor closed-source spul.
  • Meerdere packages maken voor 2 of 3 distributies. - Meer werklast, en daar komt dan rotzooi bij kijken zoals het ondersteunen van Debian-Stable of Ubuntu, waar alle libraries stokoude versies zijn of waarin bepaalde features uitgezet zijn.
  • Statically linked binaries online dumpen. - Werkt goed voor kleine dingen, maar bij grote projecten wordt dat een onbruikbare puinhoop.
Flatpak heeft het positieve van het laatste, maar niet de nadelen. Je applicatie is makkelijk te delen en installeren ongeacht de distributie van de gebruiker, en je hebt een vaste 'target' qua libraries die alsnog onafhankelijk van jouw applicatie updates krijgen.
Nice, power to the people! Pop_OS heeft Flathub ook standaard aan staan en dat is toch wel heel praktisch. De kwaliteit van de geboden packages is over het algemeen ook goed in mijn ervaring.
Volgens mij is het het tegenovergestelde. Komen de gangbare package-managers ergens iets te kort dat het een alternatief systeem vereist? Het verschil tussen apps en applicaties bestaat alleen maar in commercieel perspectief. Wat zijn we precies aan het toevoegen?
Sandboxing, permission control, de juiste lib versies, etc.

Zijn dat al genoeg voordelen? Of wil je nog even losgaan over hoe goed package managers zijn?
Klinkt als allemaal technieken die niet direct met een package/prog/app-repo te maken hebben...
Nooit geweten dat het zo was omdat ik zelf altijd gewoon Flathub toevoeg, fijn omdat te weten dat het voortaan normale Flathub word en niet en gelimiteerde.
Dat is erg fijn. Het is voor mij de standaard softwarewinkel, los van de distro die ik op dat moment gebruik.
wat ik perssoonlijk vaak jammer vind aan goed rond flathub en soortgenootjes is dat je vooral bij de ubuntu's en linux mint's van deze wereld maar moeilijk kunt zijn of je nu met het flathub, snap of distro-package te maken hebt

problemen met flatpacs en snapd packages is namelijk dat je niet op een eenduidige manier instellingen kunt aanpassen. zo kun je in een flatpack van office bijvoorbeeld heel wat moeite hebben het system thema of de usabillity instellingen van het OS over te nemen.

wat ik dus graag zou willen zien is dat men een manier verzint om per pack (of voor alle packages) een configuratie panel te maken waarbij settings van buiten de sandbox kunnen komen. settings als system-theme, DPI, toegang tot ..... etc op een manier die het ook voor standaard gebruikers eenvoudig en intuitief maakt.
iets te off-topic, sorry

[Reactie gewijzigd door sdziscool op 7 februari 2023 13:57]

EN OOK WEG MET SELINUX...!!!! WEG MET DIE ROTZOOI....!!!!

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee