Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #233807 > unrolled thread

ubuntu/snap future

Back to article view | Back to linux.debian.user

Contents

  ubuntu/snap future George Shuklin <george.shuklin@gmail.com> - 2021-04-03 18:40 +0200
    Re: ubuntu/snap future "Andrew M.A. Cater" <amacater@einval.com> - 2021-04-03 19:00 +0200
    Re: ubuntu/snap future Paul Johnson <baloo@ursamundi.org> - 2021-04-06 02:00 +0200
      Re: ubuntu/snap future Peter Ehlert <peter@sdi-baja.com> - 2021-04-06 03:10 +0200
      Re: ubuntu/snap future Yoann LE BARS <yoann@le-bars.net> - 2021-04-06 11:30 +0200
        Re: ubuntu/snap future Brian <ad44@cityscape.co.uk> - 2021-04-06 13:50 +0200
          Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-06 14:30 +0200
          ubuntu/snap future riveravaldez <riveravaldezmail@gmail.com> - 2021-04-07 05:30 +0200
            Re: ubuntu/snap future Dan Ritter <dsr@randomstring.org> - 2021-04-07 12:20 +0200
              Re: ubuntu/snap future riveravaldez <riveravaldezmail@gmail.com> - 2021-04-09 09:20 +0200
                Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 09:30 +0200
                  Re: ubuntu/snap future riveravaldez <riveravaldezmail@gmail.com> - 2021-04-09 11:40 +0200
                    Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 13:00 +0200
                      Re: ubuntu/snap future Joe <joe@jretrading.com> - 2021-04-09 15:00 +0200
                        Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 15:30 +0200
                    Re: ubuntu/snap future Andrei POPESCU <andreimpopescu@gmail.com> - 2021-04-09 19:50 +0200
                      Re: ubuntu/snap future Brian <ad44@cityscape.co.uk> - 2021-04-09 20:30 +0200
                        Re: ubuntu/snap future George Shuklin <george.shuklin@gmail.com> - 2021-04-10 16:10 +0200
                          Re: ubuntu/snap future riveravaldez <riveravaldezmail@gmail.com> - 2021-04-29 02:20 +0200
                  Re: ubuntu/snap future Yoann LE BARS <yoann@le-bars.net> - 2021-04-09 13:10 +0200
                    Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 13:40 +0200
                      Re: ubuntu/snap future Yoann LE BARS <yoann@le-bars.net> - 2021-04-09 13:50 +0200
                        Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 14:50 +0200
                          Re: ubuntu/snap future Joe <joe@jretrading.com> - 2021-04-09 15:10 +0200
                            Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 15:40 +0200
                          Re: ubuntu/snap future Stefan Monnier <monnier@iro.umontreal.ca> - 2021-04-09 17:10 +0200
                            Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 19:00 +0200
                          Re: ubuntu/snap future Yoann LE BARS <yoann@le-bars.net> - 2021-04-09 18:10 +0200
                      Re: ubuntu/snap future Andrei POPESCU <andreimpopescu@gmail.com> - 2021-04-09 19:30 +0200
                        Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 19:30 +0200
                  Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 14:10 +0200
                    Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 15:00 +0200
                      Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 15:30 +0200
                        Re: ubuntu/snap future tomas@tuxteam.de - 2021-04-09 15:40 +0200
                          Re: ubuntu/snap future The Wanderer <wanderer@fastmail.fm> - 2021-04-09 15:50 +0200
                            Re: ubuntu/snap future <tomas@tuxteam.de> - 2021-04-09 16:20 +0200
                          Re: ubuntu/snap future Charles Curley <charlescurley@charlescurley.com> - 2021-04-09 16:20 +0200
                            Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 16:30 +0200
                          Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 16:20 +0200
                      Re: ubuntu/snap future Yoann LE BARS <yoann@le-bars.net> - 2021-04-09 18:20 +0200
                    Re: ubuntu/snap future Andrei POPESCU <andreimpopescu@gmail.com> - 2021-04-09 19:50 +0200
                      Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 20:40 +0200
                        Re: ubuntu/snap future Linux-Fan <Ma_Sys.ma@web.de> - 2021-04-09 21:40 +0200
                          Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 22:10 +0200
                Re: ubuntu/snap future Celejar <celejar@gmail.com> - 2021-04-09 14:10 +0200
          Re: ubuntu/snap future George Shuklin <george.shuklin@gmail.com> - 2021-04-10 16:10 +0200

Page 1 of 3  [1] 2 3  Next page →

#233807 — ubuntu/snap future

I'd like to stir some debates.

Ubuntu (which is 'enterprise friendly Debian with ambivalent feeling 
about free software') started to push snaps onto servers for real. It 
looks to me like they desperately want to jump away from debs into 
'vendor friendly packaging'. Is it so?

[toc] | [next] | [standalone]

#233810

On Sat, Apr 03, 2021 at 07:38:53PM +0300, George Shuklin wrote:
> I'd like to stir some debates.
> 
> Ubuntu (which is 'enterprise friendly Debian with ambivalent feeling about
> free software') started to push snaps onto servers for real. It looks to me
> like they desperately want to jump away from debs into 'vendor friendly
> packaging'. Is it so?
> 

Yes, I think it might be. The problem with some packages is that they're 
impossible to keep up to date in the traditional way, seemingly, and Ubuntu
want to use snaps to make things easier to manage / quicker to update.

Lots of different ways to make a distribution: Ubuntu / MXlinux and all sorts
of others, each with their own ideas, Debian with theirs - lots of shades
of opinion dividing the pool of Linux users and Linux development talent.

Ubuntu is a commercial distribution with its own viewpoint - though when I 
first came across it (before it first released in 2005 - when it was still a
quiet discussion) it was described to me by one of the very first participants
"If we could have got away with calling it Debian for desktops, we would have
done" - so stuff has quietly changed in tha last 16 years as has the overall
profile of the distribution.

All best, 

Andy C.

[toc] | [prev] | [next] | [standalone]

#233872

[Multipart message — attachments visible in raw view] — view raw

On Sat, Apr 3, 2021 at 11:39 AM George Shuklin <george.shuklin@gmail.com>
wrote:

> It looks to me like they desperately want to jump away from debs into
> 'vendor friendly packaging'
>

There's nothing user-unfriendly about .debs.  They just don't want to
maintain their software and are looking for a "fire and forget" solution.
I can't see this as anything but a bad thing, something the world can live
without.

[toc] | [prev] | [next] | [standalone]

#233878

[Multipart message — attachments visible in raw view] — view raw

On 4/5/21 4:53 PM, Paul Johnson wrote:
> On Sat, Apr 3, 2021 at 11:39 AM George Shuklin 
> <george.shuklin@gmail.com <mailto:george.shuklin@gmail.com>> wrote:
>
>     It looks to me like they desperately want to jump away from debs into
>     'vendor friendly packaging'
>
>
> There's nothing user-unfriendly about .debs.  They just don't want to 
> maintain their software and are looking for a "fire and forget" 
> solution.  I can't see this as anything but a bad thing, something the 
> world can live without.

+1

[toc] | [prev] | [next] | [standalone]

#233885

Hello everybody out there!

On 2021/04/06 at 01:53 am, Paul Johnson wrote:
> There's nothing user-unfriendly about .debs.  They just don't want to
> maintain their software and are looking for a "fire and forget"
> solution.  I can't see this as anything but a bad thing, something the
> world can live without.

	Well, I do not like the way Ubuntu uses snaps, but there are some good
reasons to use something like snaps or flatpacks.

	Even with a less careful procedure to integrate and  update packages
than the one of Debian (which I like), create a new package and update
one take some time. There are several examples when a user needs a bug
fix or some functionality that packages in distributions do not provide.
In such a case, without snaps or flatpacks, the user has to compile the
program, which need some technical skills and can be sometimes really
tricky. Appimages are less interesting, as you have to update them manually.

	Use parsimoniously, packages like snaps or flatpacks are something very
useful, which improve user experience even for power users. The problem
with Ubuntu is it uses way too much snaps and I do not think it is a
matter of laziness.

	Best regards.

-- 
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : ylebars@framasphere.org

[toc] | [prev] | [next] | [standalone]

#233894

On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote:

> 
> Hello everybody out there!
> 
> On 2021/04/06 at 01:53 am, Paul Johnson wrote:
> > There's nothing user-unfriendly about .debs.  They just don't want to
> > maintain their software and are looking for a "fire and forget"
> > solution.  I can't see this as anything but a bad thing, something the
> > world can live without.
> 
> 	Well, I do not like the way Ubuntu uses snaps, but there are some good
> reasons to use something like snaps or flatpacks.
> 
> 	Even with a less careful procedure to integrate and  update packages
> than the one of Debian (which I like), create a new package and update
> one take some time. There are several examples when a user needs a bug
> fix or some functionality that packages in distributions do not provide.
> In such a case, without snaps or flatpacks, the user has to compile the
> program, which need some technical skills and can be sometimes really
> tricky. Appimages are less interesting, as you have to update them manually.
> 
> 	Use parsimoniously, packages like snaps or flatpacks are something very
> useful, which improve user experience even for power users. The problem
> with Ubuntu is it uses way too much snaps and I do not think it is a
> matter of laziness.

I had occasion to install Zoom a few weeks ago;'snap install zoom-client'.
Everything went smoothly and I quite like having this proprietary package
strictly confined.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#233896

On Tue, 6 Apr 2021 12:49:14 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote:
> 
> > 
> > Hello everybody out there!
> > 
> > On 2021/04/06 at 01:53 am, Paul Johnson wrote:
> > > There's nothing user-unfriendly about .debs.  They just don't want to
> > > maintain their software and are looking for a "fire and forget"
> > > solution.  I can't see this as anything but a bad thing, something the
> > > world can live without.
> > 
> > 	Well, I do not like the way Ubuntu uses snaps, but there are some good
> > reasons to use something like snaps or flatpacks.
> > 
> > 	Even with a less careful procedure to integrate and  update packages
> > than the one of Debian (which I like), create a new package and update
> > one take some time. There are several examples when a user needs a bug
> > fix or some functionality that packages in distributions do not provide.
> > In such a case, without snaps or flatpacks, the user has to compile the
> > program, which need some technical skills and can be sometimes really
> > tricky. Appimages are less interesting, as you have to update them manually.
> > 
> > 	Use parsimoniously, packages like snaps or flatpacks are something very
> > useful, which improve user experience even for power users. The problem
> > with Ubuntu is it uses way too much snaps and I do not think it is a
> > matter of laziness.
> 
> I had occasion to install Zoom a few weeks ago;'snap install zoom-client'.
> Everything went smoothly and I quite like having this proprietary package
> strictly confined.

'apt install zoom_amd64.deb' goes smoothly as well. Confinement is
certainly a good thing - I'll have to look into whether the snap route
is preferable to the firejail solution that I currently use.

Celejar

[toc] | [prev] | [next] | [standalone]

#233907

[Multipart message — attachments visible in raw view] — view raw

On Tuesday, April 6, 2021, Brian <ad44@cityscape.co.uk> wrote:
> On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote:
>
> I had occasion to install Zoom a few weeks ago;'snap install zoom-client'.
> Everything went smoothly and I quite like having this proprietary package
> strictly confined.

Hi, I was under the impression that (besides being fully open) Flatpack had
better confinement method that Canonical's Snap, anybody knows if this is
correct?

Kind regards.

[toc] | [prev] | [next] | [standalone]

#233920

riveravaldez wrote: 
> On Tuesday, April 6, 2021, Brian <ad44@cityscape.co.uk> wrote:
> > On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote:
> >
> > I had occasion to install Zoom a few weeks ago;'snap install zoom-client'.
> > Everything went smoothly and I quite like having this proprietary package
> > strictly confined.
> 
> Hi, I was under the impression that (besides being fully open) Flatpack had
> better confinement method that Canonical's Snap, anybody knows if this is
> correct?


"Two years ago I wrote about then heavily-pushed Flatpak,
self-proclaimed "Future of Apps on Linux". The article
criticized the following three major flows in Flatpak:

    Most of the apps have full access to the host system but
        users are misled to believe the apps are sandboxed
    The flatpak runtimes and apps do not get security updates
    Flatpak breaks many aspects of desktop integration"

    -- https://flatkill.org/2020/


(the article then says that they fixed some desktop integration
issues)

-dsr-

[toc] | [prev] | [next] | [standalone]

#234008

On 4/7/21, Dan Ritter <dsr@randomstring.org> wrote:
> riveravaldez wrote:
>> On Tuesday, April 6, 2021, Brian <ad44@cityscape.co.uk> wrote:
>> > On Tue 06 Apr 2021 at 11:20:58 +0200, Yoann LE BARS wrote:
>> >
>> > I had occasion to install Zoom a few weeks ago;'snap install
>> > zoom-client'.
>> > Everything went smoothly and I quite like having this proprietary
>> > package
>> > strictly confined.
>>
>> Hi, I was under the impression that (besides being fully open) Flatpak
>> had
>> better confinement method that Canonical's Snap, anybody knows if this is
>> correct?
>
>
> "Two years ago I wrote about then heavily-pushed Flatpak,
> self-proclaimed "Future of Apps on Linux". The article
> criticized the following three major flows in Flatpak:
>
>     Most of the apps have full access to the host system but
>         users are misled to believe the apps are sandboxed
>     The flatpak runtimes and apps do not get security updates
>     Flatpak breaks many aspects of desktop integration"
>
>     -- https://flatkill.org/2020/
>
> (the article then says that they fixed some desktop integration
> issues)

Thanks a lot for the link and info, Dan, very informative.

I'm still with the doubt. Even considering all this: which has better
(or less-worse) confinement, Flatpak or Snap (or AppImage)?

Trying to decide which is less-worse in a scenario of unavoidable
use of some of these.

Thanks again!

[toc] | [prev] | [next] | [standalone]

#234010

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote:

[...]

> Trying to decide which is less-worse in a scenario of unavoidable
> use of some of these.

Is it really unavoidable? Or just a tad less convenient?

Can you pose one concrete use case where it is unavoidable?

This may sound as an attempt to troll. This is (by far) not my
intention. I'd rather like to try to analyse the trade-offs based
on that use case.

For example: would a more broad availability of backports reduce
the need for snaps, flats or how they may be called?

Such kind of questions.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#234012

On 4/9/21, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote:
>
> [...]
>
>> Trying to decide which is less-worse in a scenario of unavoidable
>> use of some of these.
>
> Is it really unavoidable? Or just a tad less convenient?

Well, that's a pretty subjective issue, to be honest... ;)

> Can you pose one concrete use case where it is unavoidable?

Not sure if *unavoidable* but I didn't found a better solution at the
time:
A client for which laptop I'd installed Debian was in job-need of
using Skype and Zoom. Her employers wouldn't use anything
else, so, I was looking for the better/safer way to install such damn
closed-source pieces of soft (in particular I hate Zoom, but that's
another subjective issue...) in a for anything else fully libre/secure
perfectly working Debian system.
I have no idea what the official .deb packages from Skype/Zoom
do, so, to minimize exposition and control-lost looked for an easy
way to 'enclose' what those programs could do, and opted finally
for Flatpak just to avoid any Canonical late-inconvenience...

While typing this I've checked and found that both Zoom and Skype
seem to offer through-browser video-call right now (Skype only for
Chrome, and I'm not sure if it works for Chromium). So, right now
this case only would be relevant for Skype let's say. (Anyway, I've
found that specific-application performance is usually superior that
through-browser performance when using video-calls, specially
notorious in old boxes.)

> This may sound as an attempt to troll.

Not coming from you, obviously. ^_^

> This is (by far) not my intention. I'd rather like to try to analyse
> the trade-offs based on that use case.

As any gentle and very intelligent person would do. Naturally.

> For example: would a more broad availability of backports reduce
> the need for snaps, flats or how they may be called?
>
> Such kind of questions.

Well, that's an excellent point, and I think that, in general, the answer
will be 'yes', at least thinking in the use of newer packages in Stable.
But I'm a Testing user, so, not sure if this assumption has any value.

In the other hand, for proprietary software -when unavoidable- what
would be better/simpler way to have it under control (if such thing is
somehow possible)?

> Cheers
>  - t

Thanks a lot for your answers and help. Regards!

[toc] | [prev] | [next] | [standalone]

#234015

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 09, 2021 at 06:34:32AM -0300, riveravaldez wrote:
> On 4/9/21, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > On Fri, Apr 09, 2021 at 04:15:07AM -0300, riveravaldez wrote:
> >
> > [...]
> >
> >> Trying to decide which is less-worse in a scenario of unavoidable
> >> use of some of these.
> >
> > Is it really unavoidable? Or just a tad less convenient?
> 
> Well, that's a pretty subjective issue, to be honest... ;)

Of course.
> 
> > Can you pose one concrete use case where it is unavoidable?
> 
> Not sure if *unavoidable* but I didn't found a better solution at the
> time:
> A client for which laptop I'd installed Debian was in job-need of
> using Skype and Zoom.

Thanks for the example.

>                      Her employers wouldn't use anything
> else, so, I was looking for the better/safer way to install such damn
> closed-source pieces of soft (in particular I hate Zoom, but that's
> another subjective issue...) in a for anything else fully libre/secure
> perfectly working Debian system.

[...]

Makes sense. Of course, some VM deployment could be even a tad
more secure, but if you look deep down, all security is moot when
you give the app direct access to, say, the GPU. And even assuming
a video app could work satisfactorily with a virtualised GPU (I
never tried!), I don't think current implementations are remotely
secure. But I'm no expert in there.

> While typing this I've checked and found that both Zoom and Skype
> seem to offer through-browser video-call right now (Skype only for
> Chrome, and I'm not sure if it works for Chromium). So, right now
> this case only would be relevant for Skype let's say. (Anyway, I've
> found that specific-application performance is usually superior that
> through-browser performance when using video-calls, specially
> notorious in old boxes.)

Yes, Zoom has a web client, I helped a friend of mine through her
steps with that. What I noticed was that it has less features than
the native client: this was at times confusing, because her peer
told her to push this-and-that button on the UI, which weren't in
the web version.

I think this is intentional on Zoom's part. They're in the "embrace"
phase: suck in people even if they are reluctant to commit to the
whole gorilla (aka the "native app"). Whenever they think there's
enough fish securely in their net, they'll start the "squeeze" phase.

Capitalists are like that.

> > This may sound as an attempt to troll.
> 
> Not coming from you, obviously. ^_^

Thanks ♥

But I'm human, too, and I do horrible things from time to time.

> As any gentle and very intelligent person would do. Naturally.

This is nearly too kind of you. Thanks, again.

> > For example: would a more broad availability of backports reduce
> > the need for snaps, flats or how they may be called?
> >
> > Such kind of questions.
> 
> Well, that's an excellent point, and I think that, in general, the answer
> will be 'yes', at least thinking in the use of newer packages in Stable.
> But I'm a Testing user, so, not sure if this assumption has any value.
> 
> In the other hand, for proprietary software -when unavoidable- what
> would be better/simpler way to have it under control (if such thing is
> somehow possible)?

Up to now, I've avoided the problem. I think I'd try to go with a VM,
or, if possible, with a small and nearly-disposable thingy, like a
Raspberry Pi.

A setup I'd like to see is a Raspi or similar, with a minimal boot
"drive" (SD card) having its image on my "main" computer (the Pi 4
can even boot off the net natively), via NBD or some network file
system, where I can pick and choose what to boot. A kind of
externalised VM, if you like. Ah, projects :)

> Thanks a lot for your answers and help. Regards!

Thank you, cheers
 - t

[toc] | [prev] | [next] | [standalone]

#234024

On Fri, 9 Apr 2021 12:51:14 +0200
<tomas@tuxteam.de> wrote:


> 
> Capitalists are like that.
> 

Non-capitalists (i.e. governments) don't need to be, they simply
imprison you if you don't do things their way. I still have a choice
whether to use Zoom, etc., or at least a choice whether to install it
on a computer I value. I don't have a choice about using government
software.

> Up to now, I've avoided the problem. I think I'd try to go with a VM,
> or, if possible, with a small and nearly-disposable thingy, like a
> Raspberry Pi.
> 

Indeed. The Pi4 is quite powerful.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#234029

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 09, 2021 at 01:55:21PM +0100, Joe wrote:
> On Fri, 9 Apr 2021 12:51:14 +0200
> <tomas@tuxteam.de> wrote:
> 
> 
> > 
> > Capitalists are like that.
> > 
> 
> Non-capitalists (i.e. governments) don't need to be [...]

(responded in private, to avoid starting an OT flood :)

> > Up to now, I've avoided the problem. I think I'd try to go with a VM,
> > or, if possible, with a small and nearly-disposable thingy, like a
> > Raspberry Pi.
> > 
> 
> Indeed. The Pi4 is quite powerful.

Yep :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#234051

[Multipart message — attachments visible in raw view] — view raw

On Vi, 09 apr 21, 06:34:32, riveravaldez wrote:
> On 4/9/21, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> >
> > Is it really unavoidable? Or just a tad less convenient?
> 
> Well, that's a pretty subjective issue, to be honest... ;)
> 
> > Can you pose one concrete use case where it is unavoidable?
> 
> Not sure if *unavoidable* but I didn't found a better solution at the
> time:
> A client for which laptop I'd installed Debian was in job-need of
> using Skype and Zoom. Her employers wouldn't use anything
> else, so, I was looking for the better/safer way to install such damn
> closed-source pieces of soft (in particular I hate Zoom, but that's
> another subjective issue...) in a for anything else fully libre/secure
> perfectly working Debian system.
> I have no idea what the official .deb packages from Skype/Zoom
> do, so, to minimize exposition and control-lost looked for an easy
> way to 'enclose' what those programs could do, and opted finally
> for Flatpak just to avoid any Canonical late-inconvenience...

Just a general reminder: dpkg will execute all maintainer scripts 
contained in the package as root.

Packages can also contain various other files that can have a big impact 
on system security, like system .service files, cron jobs/timers running 
as root, SUID binaries, etc., even if the program itself is (meant to 
be) run only as a regular user.

If you care about the security of your system inspecting the .deb before 
'dpkg -i' is always a good idea (e.g. with mc or so).

If you are adding foreign repositories you are also trusting them for 
all package updates, for *any* package on your system.

By default APT doesn't care from which repository a particular package 
is coming from, as long as it has the higher version, and that is easy 
enough to manipulate (e.g. with an epoch). A trusted repository could 
then easily substitute *any* package on your system (kernel, init, 
shell, etc.) via package upgrades.

The repository doesn't even have to be evil, as it could always be 
hijacked by a bad actor.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#234054

On Fri 09 Apr 2021 at 20:43:58 +0300, Andrei POPESCU wrote:

> On Vi, 09 apr 21, 06:34:32, riveravaldez wrote:
> > On 4/9/21, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > >
> > > Is it really unavoidable? Or just a tad less convenient?
> > 
> > Well, that's a pretty subjective issue, to be honest... ;)
> > 
> > > Can you pose one concrete use case where it is unavoidable?
> > 
> > Not sure if *unavoidable* but I didn't found a better solution at the
> > time:
> > A client for which laptop I'd installed Debian was in job-need of
> > using Skype and Zoom. Her employers wouldn't use anything
> > else, so, I was looking for the better/safer way to install such damn
> > closed-source pieces of soft (in particular I hate Zoom, but that's
> > another subjective issue...) in a for anything else fully libre/secure
> > perfectly working Debian system.
> > I have no idea what the official .deb packages from Skype/Zoom
> > do, so, to minimize exposition and control-lost looked for an easy
> > way to 'enclose' what those programs could do, and opted finally
> > for Flatpak just to avoid any Canonical late-inconvenience...
> 
> Just a general reminder: dpkg will execute all maintainer scripts 
> contained in the package as root.
> 
> Packages can also contain various other files that can have a big impact 
> on system security, like system .service files, cron jobs/timers running 
> as root, SUID binaries, etc., even if the program itself is (meant to 
> be) run only as a regular user.
> 
> If you care about the security of your system inspecting the .deb before 
> 'dpkg -i' is always a good idea (e.g. with mc or so).
> 
> If you are adding foreign repositories you are also trusting them for 
> all package updates, for *any* package on your system.
> 
> By default APT doesn't care from which repository a particular package 
> is coming from, as long as it has the higher version, and that is easy 
> enough to manipulate (e.g. with an epoch). A trusted repository could 
> then easily substitute *any* package on your system (kernel, init, 
> shell, etc.) via package upgrades.
> 
> The repository doesn't even have to be evil, as it could always be 
> hijacked by a bad actor.

In response to this well-argued post: which is less risky when not
installing a package from the archives?

  * Install the vendor .deb.
  * Install from the snap store.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#234071

On 4/9/21 9:26 PM, Brian wrote:
> In response to this well-argued post: which is less risky when not
> installing a package from the archives?
>
>    * Install the vendor .deb.
>    * Install from the snap store.
>
Both are providing about the same level of isolation. One can make more 
bad things with your system files, but... https://xkcd.com/1200/

If you need to run more-or-less trusted proprietary vendor, use VM. If 
you need to run untrusted blob, use separate machine.

[toc] | [prev] | [next] | [standalone]

#234600

On 4/7/21, Dan Ritter <dsr@randomstring.org> wrote:
>> riveravaldez wrote:
>>
>> Hi, I was under the impression that (besides being fully open) Flatpak
>> had
>> better confinement method that Canonical's Snap, anybody knows if this is
>> correct?
>
> "Two years ago I wrote about then heavily-pushed Flatpak,
> self-proclaimed "Future of Apps on Linux". The article
> criticized the following three major flows in Flatpak:
>
>     Most of the apps have full access to the host system but
>         users are misled to believe the apps are sandboxed
>     The flatpak runtimes and apps do not get security updates
>     Flatpak breaks many aspects of desktop integration"
>
>     -- https://flatkill.org/2020/
>
> (the article then says that they fixed some desktop integration
> issues)

Hi, just in case anyone is interested in the following of this, I've
asked at Flatpak's mail-list about the issues mentioned in that
article and someone from GNOME pointed me to this post[0],
which I still didn't read. So, at the moment, just reporting. ;)

Best regards.

[0] https://ramcq.net/2018/10/15/flatpak-sandbox-security/

[toc] | [prev] | [next] | [standalone]

#234017

Hello everybody out there!

On 2021/04/09 at 09:21 am, tomas@tuxteam.de wrote:
> Can you pose one concrete use case where it is unavoidable?

	I have found some bugs in Musescore that are corrected on a higher
version than the one available in stable.

	I need some functionalities available in Ardour 6, which is not
available in stable.

> For example: would a more broad availability of backports reduce
> the need for snaps, flats or how they may be called?

	If those two where available in backports, I definitively would use
these versions.

	Now, I need Discord and the only version which works after an update is
the one available as a snap.

	I have also been asked to use Microsoft Teams. Well, this one never
really works, either as a deb, a snap or a flatpak…

	Concerning the few proprietary softwares I use, I think I rather use
something like snap or flatpak—I have no preferences, save the fact I
rather have the possibility to set up y own server.

	Now, I have develop a few small applications who do not have much users
and are not in the position to integrate the distribution. For the few
users of these programs, it is way easier for them that I give an
Appimage or a Flatpak.

	Best regards.

-- 
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : ylebars@framasphere.org

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web