[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ELPA] new package: tramp-docker
From: |
Philip Kaludercic |
Subject: |
Re: [ELPA] new package: tramp-docker |
Date: |
Sun, 16 Oct 2022 13:33:37 +0000 |
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > But you also don't need to
> > use the site itself, the "docker"/"podman" commands take care of
> > fetching everything you need, just like "apt-get" would.
>
> apt-get fetches lists of packages from a web site, and then fetched
> the packages themselves from it too. Is that what the `docker' and
> `podman' commands do? It looks that way. If so, then running them
> is a way of using the respective sites, not an alternative to doing so.
>
> Accessing the site that way has an advantage: if `docker' and `podman'
> are free programs, and assuming they don't silently run any software
> fetched from the site, this avoids the danger that browsing the site
> would run nonfree JS code.
This is my understanding as well, albeit as someone who has never taken
the time to take a look at the internal details of how this is
implemented.
> So far, so much the better. But that leaves this problem:
>
> > > Is there an easy way you can ensure that _all_ the programs you put
> > > into a new container are free? Is there an easy way to verify that
> > > the contents of a container are free?
>
> > Without an index that would only host free software, I don't see how
> > this would currently be possible.
>
> That's what I expected. Alas, the natural consequence is that
> building containers implies a risk of including nonfree software. The
> more packages, the more risk.
>
> As long as that is the case, we should warn people off of distributing
> containers.
>
> GNU Emacs is not the place to publish that general point, but where we
> mention support for containers, let's include this.
>
> Containers pose problems for software freedom. If you are careful,
> you can make and then use a container with only free packages. But
> when you make a container with more than a few packages, there is
> nothing to help you make sure each and every one is free/libre, and
> no easy way to verify this for an existing container. We recommend
> staying away from containers made by others unless they explicitly
> commit to carefully ensure the whole contents are free/libre.
I think this sounds good.
- Re: [ELPA] new package: tramp-docker, Philippe Vaucher, 2022/10/03
- Re: [ELPA] new package: tramp-docker, Brian Cully, 2022/10/03
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/06
- Re: [ELPA] new package: tramp-docker, Philip Kaludercic, 2022/10/07
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/08
- Re: [ELPA] new package: tramp-docker, Philip Kaludercic, 2022/10/09
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/15
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/15
- Re: [ELPA] new package: tramp-docker,
Philip Kaludercic <=
- Re: [ELPA] new package: tramp-docker, zimoun, 2022/10/17
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/19
- Re: [ELPA] new package: tramp-docker, zimoun, 2022/10/20
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/22
- Re: [ELPA] new package: tramp-docker, Richard Stallman, 2022/10/15
- Re: [ELPA] new package: tramp-docker, Brian Cully, 2022/10/10
- Re: [ELPA] new package: tramp-docker, zimoun, 2022/10/12
Re: [ELPA] new package: tramp-docker, Payas Relekar, 2022/10/16