On 19.11.18 20:24, gregor herrmann wrote:
> On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
>
> (OT, but since I noticed it too:)
>
>> Anyways, Skype doesn't work since 8.30 as it crashes directly on
>> startup.
>
> Apparently it needs (e)logind since that version.
T
On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
(OT, but since I noticed it too:)
> Anyways, Skype doesn't work since 8.30 as it crashes directly on
> startup.
Apparently it needs (e)logind since that version.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at
On 07.10.18 21:20, Adrian Bunk wrote:
> For leaf software like Skype or Chrome, approaches like flatpak where>
> software can be installed by non-root users and then runs confined>
have a more realistic chance of being able to becoming a good solution.
I'd rather put those non-trustworthy code th
On Sun, Oct 07, 2018 at 01:06:54PM +0200, Tomas Pospisek wrote:
I think Linux systems per se, Debian as a runtime, the (social)
processes required from DDs/DMs, the whole technical Debian packaging
ecosystem are each plenty complex enough already.
…
they IMHO should serve as a dimension to meas
On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:
>...
> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare
On 3 Oct 2018 Lars Wirzenius wrote:
> A suggestion: we restrict where packages can install files and what
maintainer scripts can do.
On 4 Oct 2018 Enrico Weigelt wrote:
> Finally, I'd really like to reduce complexity, not introduce even more.
+1
I think Linux systems per se, Debian as a runtim
Laurent Bigonville writes:
> Lars Wirzenius wrote:
>
>> * default: install files in /usr only
>> * kernel: install files in /boot, trigger initramfs
>> * core: can install files anywhere, trigger anything
>> * maintained-by-liw: full power to do anything
>>
>> This might be implemented in various
Lars Wirzenius wrote:
* default: install files in /usr only
* kernel: install files in /boot, trigger initramfs
* core: can install files anywhere, trigger anything
* maintained-by-liw: full power to do anything
This might be implemented in various ways. For example, dpkg could
create a tempora
On 10/4/18 12:23 PM, Jonathan Dowland wrote:
> On Thu, Oct 04, 2018 at 12:09:05PM +0200, Thomas Goirand wrote:
>> And prevent stuff like with the bumblebee uninstall disaster because of
>> an added space, for example:
>>
>> rm -rf /usr /share/foo/bar.conf
>
> Yes, or the similar bug in steam-for-l
On Fri, Oct 5, 2018 at 3:20 AM Simon Richter wrote:
> We could bring the same to dpkg by moving things out of maintainer scripts
> and into control files. The big items would be
>
> - alternatives
> - diversions
> - statoverride
> - service start/stop
The dpkg maintainers have this on their r
On 2018-10-04 21:10, Simon Richter wrote:
> We could bring the same to dpkg by moving things out of maintainer scripts
> and into control files. The big items would be
>
> - alternatives
> - diversions
> - statoverride
> - service start/stop
I agree and like to add:
- create system users/gro
Hi,
> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare they that they intend to do that.
I've held a short inflammator
On Thu, Oct 04, 2018 at 01:27:29PM +0200, Enrico Weigelt, metux IT consult
wrote:
> Yes, that would have to be customized per-package, but we're only
> talking about a hand full of packages, anyways.
Eh, no.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, tr
On Thu, Oct 04, 2018 at 11:07:37AM +0200, W. Martin Borgert wrote:
> On 2018-10-03 23:30, Antoine Beaupré wrote:
> > There
> > are somewhat low-hanging fruits in there like declarative maintainer
> > scripts.
>
> I am very much in favour of declarative maintainer scripts!
> AFAIK, Niels Thykier ha
Paul Wise:
> On Thu, Oct 4, 2018 at 11:31 AM Antoine Beaupré wrote:
>> Beyond this issue, what I'm mostly concerned about these days is
>> isolation between different apps. Our only solution on the desktop right
>> now is Qubes and it seems rather overengineered for my needs.
> Our solution here i
On 04.10.2018 13:17, Enrico Weigelt, metux IT consult wrote:
>> (Note that I'm not saying Microsoft or Google are doing something
>> nefarious here:
>
> But I do think that. If they really wanted to do that in a reasonably
> secure and safe way (assuming they're not completely incompetent),
> the
Le 04/10/2018 à 13:20, Paride Legovini a écrit :
> Lars Wirzenius wrote on 03/10/2018:
>> The problem: when a .deb package is installed, upgraded, or removed,
>> the maintainer scripts are run as root and can thus do anything.
>>
>> Sometimes what they do is an unwelcome surprise to the user. For
>
On 04.10.2018 01:19, Carl-Valentin Schmitt wrote:
> It would be a possibility, for safety to create a new directory only for
> brandy 3rd-party-software like skype, Google Chrome, Swift, and else
> Software where huge companies are Sponsors.
>
> This would then mean, to create a second sources li
Lars Wirzenius wrote on 03/10/2018:
> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
>
> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Skype .deb and the Google Chro
On 03.10.2018 19:19, Lars Wirzenius wrote:
> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Skype .deb and the Google Chrome .deb add to
> the APT sources lists and APT accepted signing keys. Some users do not
> realise this, and are unpleasantly surprise
On Thu, Oct 04, 2018 at 12:09:05PM +0200, Thomas Goirand wrote:
And prevent stuff like with the bumblebee uninstall disaster because of
an added space, for example:
rm -rf /usr /share/foo/bar.conf
Yes, or the similar bug in steam-for-linux steam.sh. Although neither
made it into the Debian arc
On Thu, Oct 04, 2018 at 01:19:43AM +0200, Carl-Valentin Schmitt wrote:
It would be a possibility, for safety to create a new directory only for
brandy 3rd-party-software like skype, Google Chrome, Swift, and else
Software where huge companies are Sponsors.
This would then mean, to create a secon
On 10/4/18 10:06 AM, Jonathan Dowland wrote:
> On Wed, Oct 03, 2018 at 11:30:40PM -0400, Antoine Beaupré wrote:
>> Yet I still think we should start fixing those problems.
>
> +1
>
>> Yes, there are a billion things that could go wrong in the current
>> approach, but if we had *some* safety net,
On 10/4/18 1:19 AM, Carl-Valentin Schmitt wrote:
> It would be a possibility, for safety to create a new directory only for
> brandy 3rd-party-software like skype, Google Chrome, Swift, and else
> Software where huge companies are Sponsors.
>
> This would then mean, to create a second sources lis
On 2018-10-03 23:30, Antoine Beaupré wrote:
> There
> are somewhat low-hanging fruits in there like declarative maintainer
> scripts.
I am very much in favour of declarative maintainer scripts!
AFAIK, Niels Thykier has done a lot of work there, while Ralf
Treinen and colleagues are analysing maint
On 2018-10-04 09:06, Jonathan Dowland wrote:
> What about running Chromium as root? Certainly not recommended, but what
> are the user's expectations if they try it anyway?
With nowadays web, I would disallow this by default. If root
types their sentence ("Yes, I know..."), they can shoot themself
* Simon McVittie:
> On Thu, 04 Oct 2018 at 08:34:15 +0200, Florian Weimer wrote:
>> * Paul Wise:
>> > To fully solve the problem you need a whitelist based approach that
>> > ends up something completely different like Flatpak.
>>
>> Flatpaks don't work this way. Try installing gedit and open a
On Wed, Oct 03, 2018 at 11:30:40PM -0400, Antoine Beaupré wrote:
Yet I still think we should start fixing those problems.
+1
Yes, there are a billion things that could go wrong in the current
approach, but if we had *some* safety net, controlled in the
sources.list file, we could at least res
On Thu, 04 Oct 2018 at 08:34:15 +0200, Florian Weimer wrote:
> * Paul Wise:
> > To fully solve the problem you need a whitelist based approach that
> > ends up something completely different like Flatpak.
>
> Flatpaks don't work this way. Try installing gedit and open a file
> like ~/.ssh/id_rsa
On Thu, Oct 4, 2018 at 3:24 PM Florian Weimer wrote:
> Flatpaks don't work this way. Try installing gedit and open a file
> like ~/.ssh/id_rsa with it. There are no security prompts whatsoever,
> yet the software in a flatpak can read your SSH private key.
AFAIK, the only way a Flatpak can read
* Paul Wise:
> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.
Flatpaks don't work this way. Try installing gedit and open a file
like ~/.ssh/id_rsa with it. There are no security prompts whatsoever,
yet the software in
On Thu, Oct 4, 2018 at 11:31 AM Antoine Beaupré wrote:
> Yes well, we *could* consider rewriting Debian to be based on
> appimage/flatpak/snappy, but that would be a rather controversial
> change. I think there are smaller, incremental steps we can take before
> that to improve the situation witho
Hi!
On Thu, 2018-10-04 at 08:38:09 +0800, Paul Wise wrote:
> On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:
> > The problem: when a .deb package is installed, upgraded, or removed,
> > the maintainer scripts are run as root and can thus do anything.
Paul prompted a similar discussion the ot
On 2018-10-04 08:38:09, Paul Wise wrote:
> On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:
>
>> The problem: when a .deb package is installed, upgraded, or removed,
>> the maintainer scripts are run as root and can thus do anything.
>
> anarcat wrote this related wiki page that covers this gen
On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:
> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
anarcat wrote this related wiki page that covers this general topic:
https://wiki.debian.org/UntrustedDeb
It would be a possibility, for safety to create a new directory only for
brandy 3rd-party-software like skype, Google Chrome, Swift, and else
Software where huge companies are Sponsors.
This would then mean, to create a second sources list for 3rd-party-links.
Carl-Valentin Schmitt schrieb am
in /usr only ?...
I thought therefore in later years Linux had created /opt ?
Lars Wirzenius schrieb am Mi., 3. Okt. 2018, 19:19:
> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
>
> Sometimes what they d
On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:
> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
>
> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Sk
On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:
A suggestion: we restrict where packages can install files and what
maintainer scripts can do. The default should be as safe as we can
make it, and packages that need to do things not allowed by the
default should declare they that t
39 matches
Mail list logo
