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

Ubuntu's snap-apps werken nu op praktisch elke Linux-distributie

Canonical heeft aangekondigd dat de mogelijkheid om 'snap'-packages te installeren is geport naar andere Linux-distributies. Om precies te zijn is of wordt snapd geport naar onder andere Arch, Fedora, Debian, RHEL, CentOS en Gentoo.

Daarmee moet het in theorie makkelijker worden om applicaties voor verschillende distributies aan te bieden, doordat alle afhankelijkheden of dependencies in de snap-package zijn verpakt. Canonical ontwikkelde het snap-systeem in eerste instantie voor Ubuntu Phone en Ubuntu Snappy Core, zodat applicaties in hun eigen container draaien en zo een kleiner beveiligingsrisico vormen.

Met het snapcraft.io-platform hoopt Canonical deze vorm van pakketbeheer voor Linux tot een standaard te verheffen. Met snaps moet het voor ontwikkelaars makkelijker worden om software te publiceren, doordat een ontwikkelaar geen verschillende repositories en andere updatemechanismen meer hoeft bij te houden. Naast updates kan een ontwikkelaar zelf ook een update terugdraaien, wat vooral handig is op apparaten zonder beeldscherm en dergelijke, zoals internet-of-things-apparaten. Ook is het mogelijk om incrementele updates toe te voegen.

Mark Shuttleworth, oprichter van Canonical, heeft tijdens een presscall gezegd dat het project niet alleen door Canonical gedragen wordt, maar ook door ontwikkelaars van andere Linux-distributies, zoals Arch en Gentoo.

Tijdens dezelfde presscall over de introductie van snapd voor andere distributies, werden ook vragen gesteld over andere systemen met een vergelijkbaar doel, zoals Flatpak, App Image en Orbital Apps. Volgens Shuttleworth wordt heden ten dage zo'n '95 procent van de commits' door één werknemer van Red Hat gedaan bij Flatpak. Flatpak is de nieuwe naam van de Freedesktop.org xdg-app en daar is ook een specifieke Ubuntu-repository van.

Een andere interessante vraag tijdens het gesprek was of het mogelijk zou zijn het systeem naar Android te porten. Volgens OMG Ubuntu was Shuttleworth' antwoord daarop dat dit een goed idee zou zijn. Hij voegde eraan toe dat 'als OpenWRT snaps in minder dan een week aan de praat heeft', hij 'verbaasd zou zijn als Android niet iets vergelijkbaars zou kunnen regelen'.

Van de bekendere grote applicaties is onder andere van LibreOffice 5.2.0 bèta 2 een snap beschikbaar. Ook Mozilla heeft aangekondigd Firefox over niet al te lange tijd als snap te willen leveren.

Door Krijn Soeteman

Freelanceredacteur

15-06-2016 • 13:16

42 Linkedin

Reacties (42)

Wijzig sortering
Van wat ik begrepen heb is het een trade-off. Een groot dev. probleem is dat sommige distro's nogal eens oudere versies van software erop na houden. Het gevolg is dat developers echt idioot veel builds moeten maken en heel veel verschillende versies moeten ondersteunen voor een enkel pakket.

Door technologie zoals Snap-packages wordt dit nadeel weg gewerkt. Een nadeel van snap is echter vervolgens weer dat men de dependancies in de packages zelf moet updaten wat een grotere verantwoordelijkheid legt bij de developers. Dit kan leiden tot (populaire) software die niet goed wordt bijgewerkt en dus ondanks de sandbox beveiligingsrisico's bij zich brengt.

Voor developers is de nieuwe methode echter eenvoudiger met implementatie en ondersteuningen en is het voor bedrijven commercieel aantrekkelijker.

That said...Snap is slechts 1 enkele technologie. Er is momenteel een soort packagewars bezig in voor de heersende package distro te worden. Ubuntu had Snap welke bij 16.04 mee kwam. Een klacht ervan destijds was dat hiermee Ubuntu zijn eigen eilandje werd. Nu is dat opgelost omdat Ubuntu alsook de community er rondomheen veel werk heeft gestoken in het porten van de technologie naar andere disto's.

Persoonlijk snap ik het beveiligingsrisico en zullen er vast wel momenten zijn waarop gebruikers daardoor in de staart worden gebeten. Echter maakt Linux momenteel een redelijke groei door en zie ik ook wel in dat nieuwe developers en softwareproducenten van traditionele platforms zoals Windows niet echt graag een O.S. in willen springen waar ze moeten kiezen voor 1 distro tak of het maken van 15 verschillende versies voor alle Linux distro's.

[Reactie gewijzigd door Auredium op 15 juni 2016 14:00]

Het is het ouderwetse probleem van dependency hell waar geen éénduidig antwoord voor is.

Dit systeem kan handig zijn, mits het wordt aangegeven wanneer de meegeleverde dependencies als onveilig worden beschouwd en in welke scenario's. Bijvoorbeeld: een OpenSSL library die kwetsbaar is voor iets als Heartbleed heeft weinig impact als het alleen lokaal in zijn eigen sandbox (geen netwerkfunctionaliteit) gebruikt wordt om hashes te genereren.

Snaps leggen de verantwoordelijkheid neer bij de ontwikkelaar. Als het die makkelijk wordt gemaakt om snel een nieuw package te genereren met alle libraries up-to-date, dan kan het iets krachtigs zijn omdat dat package (per uitgegeven update) maar éénmaal getest hoeft te worden en vervolgens op de meeste Linux distributies draait. Een ontwikkelaar kan ook besluiten om door een tijdelijke bug in een dependency een kleine downgrade te doen, wat niet altijd lijdt tot een securityprobleem, om dit vervolgens in een latere versie in te halen.

Het kan dus krachtig zijn, maar je moet verantwoordelijke ontwikkelaars hebben. Als banken die al niet hebben (zie APK's van Android die SSL/TLS verificatie niet goed uitvoerden), wat kan je dan verwachten van anderen? Ja, er zijn zat vrijwilligers met passie en liefde. En er zijn ook luie vrijwilligers en commerciële partijen die liever ergens zo min mogelijk tijd in steken.

[Reactie gewijzigd door The Zep Man op 15 juni 2016 15:33]

Ja dat zal mogelijk kunnen zijn. Ik vind t ook wat lastig in te schatten op t gebied van security zo. Ik ben al gewend om te werken met programma's zoals ze aangeboden worden in de repo. Mis ik daardoor iets wat bleeding edge is, en erg mooi, dan ga ik in de geduld modus, het komt ooit naar mijn distro (Debian testing).

Ik vraag me ook af of het kan met grotere pakketten, zoals Gnome, of je dan de nieuwste als snap kan draaien, maar dat alle bijkomende apps gewoon uit de repo kunnen komen, of dan ook snap moeten...

Voor standalone spul kan ik me hier nog wel het voordeel van voorstellen, maar ik zie mijn desktop toch min of meer als geheel met alle programma's die ik erbij heb staan. Het onderhoud is met repo-software een simpele update en 't is weer bij, maar hoe werkt dat als je 10 verschillende snaps hebt?

edit:
snaps updaten zichzelf daily blijkbaar. erg afhankelijk van de bron dus of een snap veilig is of niet. Dit gaat de nieuwe .exe worden. Software installatie op Linux wordt er toegankelijker van, maar ik zie de snaps al op elke download.com-website opduiken. Exe's geleverd met wine in een snap. En zo komen de virussen naar je distro.

Ik heb die snapverhalen even doorgelezen, maar het komt me erg hyped over. Ontwikkelaars vinden dit geweldig allemaal. Ze roepen veilig en snel, en minder gedoe voor 't packagen. Maar ik denk dat het hip is om een (sn)app achtig systeem te hebben, modern, zoals het hebben van een app op android hip is voor een bedrijf.

Ik heb nu al een aversie. Ik wil tegen een snap kunnen zeggen wat ie wel en niet mag. Mag de snap bij mijn mail? of mijn gelinkte accounts inzien? of mijn bestanden op mijn home doorbladeren? de configuratie van mijn websites en certificaten zien? Kan ik dat regelen/instellen per snap?

Ik voel me ineens hopeloos ouderwets kritisch.

[Reactie gewijzigd door Mar2zz op 15 juni 2016 13:43]

Ja dat zal mogelijk kunnen zijn. Ik vind t ook wat lastig in te schatten op t gebied van security zo. Ik ben al gewend om te werken met programma's zoals ze aangeboden worden in de repo. Mis ik daardoor iets wat bleeding edge is, en erg mooi, dan ga ik in de geduld modus, het komt ooit naar mijn distro (Debian testing).

Ik vraag me ook af of het kan met grotere pakketten, zoals Gnome, of je dan de nieuwste als snap kan draaien, maar dat alle bijkomende apps gewoon uit de repo kunnen komen, of dan ook snap moeten...
Het "probleem" word niet echt opgelost maar omzeilt door alle libs van de dev mee te leveren. Dan heb je niet meer dat "lastige" "it works on my machine"...
Alsof we alles weer statically gaan linken...
Voor standalone spul kan ik me hier nog wel het voordeel van voorstellen, maar ik zie mijn desktop toch min of meer als geheel met alle programma's die ik erbij heb staan. Het onderhoud is met repo-software een simpele update en 't is weer bij, maar hoe werkt dat als je 10 verschillende snaps hebt?
Dat werkt niet echt omdat je je rot zoekt welke lib in welke snap nou rot is. Of security flaw.
Eerst kon ik bij een CVE mn kwaadaardige lib updaten en mn systeem bijwerken. Nu zou je afhankelijk worden van deze individuele maintainers. (waar ik al niet zo'n hoge pet van op hebt als je je probleem niet GOED kan oplossen en het omzeilt met een snap)
snaps updaten zichzelf daily blijkbaar. erg afhankelijk van de bron dus of een snap veilig is of niet. Dit gaat de nieuwe .exe worden. Software installatie op Linux wordt er toegankelijker van, maar ik zie de snaps al op elke download.com-website opduiken. Exe's geleverd met wine in een snap. En zo komen de virussen naar je distro.
Inderdaad. Dat automatisch is al helemaal eng. Weg controle.
Ik heb die snapverhalen even doorgelezen, maar het komt me erg hyped over. Ontwikkelaars vinden dit geweldig allemaal. Ze roepen veilig en snel, en minder gedoe voor 't packagen. Maar ik denk dat het hip is om een (sn)app achtig systeem te hebben, modern, zoals het hebben van een app op android hip is voor een bedrijf.
Voornamelijk developers die niks willen weten van een eco systeem hemelen het de lucht in. Meeste distro maintainers doet het pijn aan de ogen. En inderdaad dit vind zijn oorsprong in de "apps" waar een hoop beunhazen zitten, die linux maar een moeilijk verhaal vinden.
Ik heb nu al een aversie. Ik wil tegen een snap kunnen zeggen wat ie wel en niet mag. Mag de snap bij mijn mail? of mijn gelinkte accounts inzien? of mijn bestanden op mijn home doorbladeren? de configuratie van mijn websites en certificaten zien? Kan ik dat regelen/instellen per snap?

Ik voel me ineens hopeloos ouderwets kritisch.
Neuh. Je hebt veel ervaring en je (terechte) gevoel geeft het signaal "uhoh" en dat is niet voor niks.
Van wat ik ervan begrijp kan men inderdaad eigen versies van libraries meeleveren in een snap. En dat betekend inderdaad ook een vergroot risico op verouderde, niet up-to-date versies van libraries op je systeem.

Het hele punt van het Debian beleid met zijn apt is net altijd geweest dat libraries gedeeld moeten worden zodat er slechts 1 iemand verantwoordelijk is voor een bepaalde bibliotheek en zodat je een bug slechts op 1 enkele plaats moet corrigeren om heel je systeem opnieuw veilig te maken. Met snaps lijkt het mij dan ook dat dit concept onderuit word gehaald en dat je iets begint te creëeren zoals de DLL hell op Windows, al zien we vandaag al wel wat software onder Linux dat zijn eigen libraries meeleverd ipv de systeemlibs te gebruiken (vooral closed source software).
Dus misschien werkt hun distributie wel met Gimp-x.y.z en LibreOffice-x.y.z, maar de makers van Gimp willen misschien helemaal niet dat je x.y.z gebruikt of wensen die versie niet te ondersteunen, omdat ze jou aanraden versie u.v.w. te gebruiken. Debian heeft daar doorgaans lak aan, dus juist dan is het ter voorkoming van DLL-hell fijn dat jij als gebruiker lak kan hebben aan Debian's package-beleid en gewoon de versie kan kiezen die de makers van de software jou adviseren.
Dat model werkt vanuit het oogpunt van de "primaire" pakketten van zo'n snap maar het gaat fourt voor alle andere software.

Stel dat Gimp en LibreOffice allebij een bepaald pakket nodig hebben zoals OpenSSL. Traditioneel heb je dan 1 kopie van libssl op je systeem en Gimp en LibreOffice zullen het daar mee moeten doen. De versie van OpenSSL die gebruikt wordt is gekozen door de packager, iemand typisch gespecialiseerd is op zo'n pakket en er alles van weet.
Als je een Snap maakt moet iemand besluiten welke versie van OpenSSL er in gestopt wordt. Zowel de ontwikkelaars van Gimp als van LibreOffice weten dat niet, het is niet hun specialiteit en ze zijn gewend om die beslissing aan de distributie over te laten. Waarschijnlijk nemen ze dus de eerste de beste versie die voor handen is en kijken ze er nooit meer naar om. Over drie jaar heb je waarschijnlijk wel de nieuwste versie van Gimp of LO maar nog steeds dezelfde versies van OpenSSL met alle bugs die daar bij horen. Herhaal dat verhaal voor de 300 andere dependencies die deze software heeft.

Sterker nog, waarschijnlijk wordt de neiging om nooit meer iets te updaten alleen maar groter. Programmeurs gaan er immers aan wennen dat ze allemaal altijd precies hetzelfde systeem gebruiken. Daarmee verdwijnt de flexibiliteit die veel software nu heeft om met wisselende omstandigheden om te gaan. Zo'n monocultuur is een incubator voor bugs. In een diverse wereld vind je complexe bugs door verschillende versies en implementaties te gebruiken. Dat voorkomt dat je onderbewust rekening gaat houden met bugs van een bepaalde implementatie.. Enige diversiteit voorkomt dat.
Dan zijn we het eens dat we het daarover oneens zijn:

-Als een LibreOffice-maker een willekeurige OpenSSL kiest, pakt hij gewoon een van de bron zonder deze te wijzigen. Juist de Debian-packager die er zogenaamd verstand van had verneukte OpenSSL en veroorzaakte een gapend veiligheidsgat: https://en.m.wikipedia.org/wiki/OpenSSL#cite_note-24

Als LibreOffice zelf snappy pakketjes maakt, kunnen juist alle LO-packagers van alle distributies helpen een goede package te maken ipv hetzelfde werk iedere keer opnieuw te doen voor iedere distributie. Nu is de LO-verpak kennis verdeeld over 10+ distributies, en die groepjes doen allemaal hetzelfde; enorme verspilling! Je laat ook niet 10 programmeurs dezelfde printer driver schrijven voor iedere distro apart.

Met Mir of Wayland kan je sandboxen: Als dan App A (of Debian) je OpenSSL verneukt hoeft App B daar geen last vam te hebben. Apps hebben dan vziw ook geen root-toegang tot het kern-systeem meer nodig, dus App A kan het kern-systeem niet meer verneuken.

De 'wisselende omstandigheden' die u roemt maken juist het ontwerp complexer (paar extra abstractie lagen om het op te lossen), en complexer betekent altijd meer bugs! In plaats van complexe bugs te vinden door diversiteit voorkom je liever complexe bugs door eenduidigheid en eenvoud.

Daarbij komt nog dat iedere keer dat App A een beveiligingsupdate heeft, deze eerst langs de pakket-beheerders van de distro moeten voordat ze worden goedgekeurd, een vertraging waardoor gebruikers onnodig lang kwetsbaar zijn.

Ik ben het natuurlijk wel met u eens in het geval van kleine minder actieve stukjes software waarbij geen updates meer geleverd worden, maar voor de grote actieve projecten wegen de voordelen zwaarder lijkt me.

[Reactie gewijzigd door kidde op 16 juni 2016 08:40]

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True