Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Canonical brengt snap-ondersteuning naar Fedora

Canonical geeft Fedora officieel ondersteuning voor snap, het verpakkingsformaat voor applicaties. De snaps zijn te gebruiken in combinatie met Fedora 24, 25 en 26. Fedora heeft al ondersteuning voor het vergelijkbare Flatpak.

Ontwikkelaars van Ubuntu leggen uit hoe Fedora-gebruikers eerst een snapd-package kunnen installeren en vervolgens hun eerste snap met de basis-libraries kunnen installeren. Wel waarschuwen ze dat de sandbox van snaps op de AppArmor-backend berust. "Aangezien Fedora niet met AppArmor is uitgerust, draaien snaps niet afgebakend." Het ontwikkelteam van snapd roept ontwikkelaars op de SELinux-backend hiervoor bij te werken.

Snap-pakketten bevatten naast het programma zelf ook de afhankelijkheden of dependencies. De voordelen zijn dat ze snel te distribueren zijn, veiligheid bieden en makkelijk te updaten zijn door de ontwikkelaar. Een alternatief is er in de vorm van Flatpaks. Die zijn bedoeld als open formaat voor alle Linux-varianten, maar de drijvende kracht erachter is Red Hat. Fedora heeft vanaf versie 24 ondersteuning voor het Flatpak-formaat.

Canonicals doel met snaps is om het formaat naar zoveel mogelijk systemen te krijgen, waaronder internet-of-thingsapparaten. Flatpaks zijn meer op distributie naar desktops gericht. Een ander verschil is dat Flatpaks geen gecentraliseerde app-winkel hebben zoals snaps.

Door Olaf van Miltenburg

Nieuwscoördinator

12-04-2017 • 10:07

34 Linkedin Google+

Reacties (34)

Wijzig sortering
NPM is een goed punt, daar kan je inderdaad kiezen voor globaal package installatie of lokaal path en je bent tevens erg flexibel. Maar hier zit ook precies het punt dat @FRidh aangeeft, bij oudere projecten verlies je mogelijk interesse/geld, gevolg zijn out-of-dated en potentieel gevaarlijke JavaScript libs, niet echt iets wat je allemaal kunt oplossen door het maar in één sandbox te draaien.

Gevolg is dus inderdaad dependencies hell, maar het is het haast onmogelijk wat je zegt dit te voorkomen. Het enige wat zou kunnen is een globale package manager die alles kan en doet, maar ook dat is niet waterdicht.
Het blijft schipperen tussen 2 kwaden. Bij de traditionele repositories zie je dat applicaties of libraries op oudere versies moeten blijven steken omdat anders iets anders stuk gaat. En het maintainen van packages voor specifieke repositories voor specifieke versies van specifieke distro's met ieder hun eigen beperkingen is ook een hel. Met een Snap ben je in 1 klap van die problemen af. Je kan eenvoudig naar de nieuwste versies van je dependencies, en je gebruikers kunnen ook eenvoudig naar de nieuwste versie van jouw applicatie, zonder dat dat gehinderd wordt doordat een andere applicatie breekt met de nieuwere versie van jouw dependency.

De keerzijde is dat alle makers van Snaps zelf verantwoordelijk zijn voor het bijhouden van hun dependencies, maar dat hoeven ze in dat geval maar voor 1 Snap te doen (als die toch overal kan draaien). Bij een applicatie die dus niet meer onderhouden wordt (of slecht onderhouden) kan dat dus betekenen dat er een vulnerable dependency bij zit. Maar die is dan wel gebonden tot de sandbox van die applicatie, wat de attack surface weer wat verkleint.
Tja, het is niet echt fair om een 19 jaar oud OS erbij te slepen... natuurlijk zijn er sindsdien dingen verbeterd, bij zowel Windows als Linux.
Het kan ook een voordeel zijn; er is geen enkele garantie dat nieuwe versies niet juist beveiligingsrisico's introduceren. Dat gebeurt ook regelmatig. Voorlopig is het nog steeds een beetje dweilen met de kraan open.
het geeft ook developers een reden om niet elke keer de laatste library/dependency te gebruiken.
Dat is geen reden, ook geen excuus, maar een kans. Ze krijgen de kans om niet de laatste versie van een library te moeten gebruiken.
Toch: Zolang die Snap packages niet in een sandbox draaien, is het een groot beveiligingsrisico, vindt je niet?
Dat is ook zeker een van de belangrijkste nadelen; ontwikkelaars moeten inderdaad hun security op orde hebben...

Er zijn overigens best wat parallellen te trekken tussen Snap/Flatpak en de wijze waarop applicaties op Apple en Android gedistribueerd en geinstalleerd worden.

[Reactie gewijzigd door zordaz op 12 april 2017 10:52]

Oud, ja. Obsolete, nee.
Dependency hell krijg je als er geen consistent systeem voor versioning is, dependencies allemaal centraal staan, je niet meerdere versies van een package kunt hebben staan, dependencies niet los bijgeleverd kunnen worden of dependencies niet op versie gelocked kunnen worden, of ontwikkelaars slordig met updates om gaan.

Zelfs al heb je al die zaken op orde, dan nog krijg je dependency hell. Het is een van de meest ingewikkelde problemen om op te lossen in de IT. Hele development methodologieen zijn er op gericht om de evolutie van software soepel te laten verlopen. En dan nog gaat het regelmatig mis.
Je hebt geen snaps nodig om je applicaties in een selinux- of apparmor jail te zetten. Dat kan prima met rpm's en deb's. Volgens mij is het security-verhaal dan ook voornamelijk zoeken naar argumenten om het systeem te promoten terwijl het eigenlijk niet zo veel oplost. Dependencies is er in ieder geval niet een van. Ik heb met rpm's en deb's ook nooit dependency-problemen, die worden allemaal op elkaar afgestemd door de distro-bouwer.
Daar breng je inderdaad een goed punt: zodra een package niet compatibel is met dependencies die in de repo's zitten (bijvoorbeeld niet de laatste ssl lib), meld ik dit als bug of probeer het opnieuw te compilen tegen de laatste versie.
Toegegeven dat dit niet voor elke gebruiker de oplossing is, maar dit lijkt me eerder een workaround die er niet hoeft te zijn. De package manager zorgt er toch juist voor dat elk pakket werkt met de juiste deps en dat het geheel logisch en gestructureerd in elkaar zit, waarom wil je hier dan vanaf stappen?

Wat nu als packages obsolete raken, die kan je dus oneindig blijven draaien maar wel met een enorm risico aan veiligheid issues, bugs en oude libraries die totaal niet matchen in de huidige GTK versie (om maar wat te noemen).

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True