Re: Limiting the power of packages
* 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 a flatpak can read your SSH private key.
Re: Re-evaluating architecture inclusion in unstable/experimental
On 03.10.2018 18:01, John Paul Adrian Glaubitz wrote: >> For s390x I can say that the port was driven without any commercial >> interest on both Aurelien's and my side > The question is though: Is there quantifiable amount of users that is > running Debian on such big iron instead of one of the Linux enterprise > distributions on the market? If the argument is about maintenance burden, > then does it justify to support Debian on s390x when the number of users > is small? And, if yes, why does that not apply to ppc64, for example? > (I would mention sparc64 here as well, but there is actually a valid > blocker which is the lack of supply of new hardware for DSA). I cannot speak to ppc64. ppc64el is useful as I'm told POWER can be competitive to Intel/AMD-based services. But I don't know how many users would run Debian. For s390x, IBM does not publicly admit that there are people running Debian, but there are a few. Almost all of them turn popcon off - most of the VMs can't talk to the internet. Of course I don't know if the availability of Ubuntu significantly changed that. They were able to invest much more time into polishing the port and most people just want some kind of Debian derivative. Historically the base system has been very well maintained by IBM, though. So the effort to keep it running has been relatively small. This recently changed somewhat, given that the primary focus is on enterprise distributions, in that stuff like Javascript interpreters don't work well. Essentially it boils down to server workloads that companies need to run, so as Docker and Go became popular, IBM implemented support for it. The same happened for v8 as used by Node. OpenJDK 9 finally comes with a JIT, so you don't have to use IBM Java anymore. And to IBM's credit, they even contributed some bits back to d-i. Although some of those still await testing and merging. The Ubuntu changes did not flow back / were not mergable as-is into Debian. It's always a tradeoff between how much work is necessary to keep the port alive and how many people use it. As long as the port keeps itself working, that's sort of fine in my experience. Once you need to sheperd a lot of things that all break (like the MIPSens historically had to, even working around broken CPUs) or need to deal with 2 GB virtual address space or don't have modern languages like Go or Rust around, it quickly approaches the point where it's not worth it anymore. Kind regards Philipp Kern
Re: News from devscripts
>- a "searchmode=plain" line option can be used to parse the full > content of a web page instead of searching only tags > (#897382), useful for JSON contents. Example: Cool, I just wrote a hack for such a functionality in one of my project :-) Cyr On Wed, Oct 3, 2018 at 5:42 PM Xavier wrote: > Dear fellow developers, > > devscripts 2.18.5 has been released and brings some new uscan features > for developers: > - in git mode, uscan is now able to verify signed tags (#827065). >Example: > > version=4 > opts="mode=git,pgpmode=gittag" \ > https://github.com/rs/net-server-mail refs/tags/v([\d\.]+) debian > > - a "searchmode=plain" line option can be used to parse the full >content of a web page instead of searching only tags >(#897382), useful for JSON contents. Example: > > version=4 > opts="searchmode=plain" \ >https://registry.npmjs.org/aes-js \ > https://registry.npmjs.com/aes-js/-/aes-js-(\d[\d\.]*)@ARCHIVE_EXT@ > > - new macro @DEB_EXT@ (#908528). Example: > > dversionmangle=~s/[\+~](debian|dfsg|ds|deb)(\.)?(\d+)?$// > >becomes: > > dversionmangle=~s/@DEB_EXT@// > > - new "auto" value for dversionmangle (#908528). The above example >becomes simply: > > dversionmangle=auto > > Hope this will be useful for you all ! > > A big thank you to Mattia for accepting these changes and for his > patience in this long work. > > NB: While making these changes uscan underwent a huge refactor, so > please file any bug you may find in this new version, and we shall fix > them for the next release. > > Cheers, > Xavier > >
Re: Limiting the power of packages
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 with it. There are no security prompts whatsoever, > yet the software in a flatpak can read your SSH private key. That particular app's whitelist presumably includes "share the entire host filesystem"; the existence of a whitelist doesn't mean the whitelist isn't large. General-purpose development tools and text editors generally have larger whitelists than more limited apps, with GNOME Builder at the extreme of least-confined. % flatpak --user install flathub org.gnome.gedit Installing in user: org.gnome.Platform.Locale/x86_64/3.28 flathub 2823e3d81b74 org.gnome.gedit/x86_64/stable flathub a03b66681bce permissions: ipc, wayland, x11 file access: host, xdg-run/dconf, ~/.config/dconf:ro \- this is why it can read arbitrary files dbus access: ca.desrt.dconf, org.gtk.vfs.* org.gnome.gedit.Locale/x86_64/stable flathub c2974b37ef08 Is this ok [y/n]: I think the intention is that GUIs like GNOME Software prompt for apps that need special permissions in a more user-friendly way, something like how Android handles app permissions, although I don't think that's actually implemented yet. I don't know specifically why gedit has the host file access permission: it's unnecessary for File->Open and File->Save As... (e.g. org.gnome.Recipes is a good example of an app that doesn't, but can still import and export recipes) but presumably some of gedit's IDE-like features involve opening files other than the one you directly asked for. smcv
Re: Limiting the power of packages
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 your SSH private key would be because you told the file portal that runs outside the Flatpak container to pass an fd of that file into the Flatpak container for the app to read. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#910265: ITP: python-yaswfp -- Python SWF parser
Package: wnpp Severity: wishlist Owner: Sophie Brun * Package name: python-yaswfp Version : 0.9.3 Upstream Author : Facundo Batista * URL : http://github.com/facundobatista/yaswfp * License : GPL-3 Programming Lang: Python Description : Python SWF parser Yet Another SWF Parser can be used as a command line program or as a module. It's a dependency of wapiti version 3.0.1 I plan to maintain the package in the Debian Python Modules Team.
Re: Limiting the power of packages
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 restrict what third-party packages would do. Not just third-party packages: this isolation feature could limit the damage that could occur from buggy maintainer scripts in Debian's own scripts too. For example, there's no reason why a package like Chromium should be able to run stuff as root. What about running Chromium as root? Certainly not recommended, but what are the user's expectations if they try it anyway? I don't know whether it's still true but at some point in the past Chromium's sandbox feature required part of it to be suid root in order to isolate itself. Yes well, we *could* consider rewriting Debian to be based on appimage/flatpak/snappy Appimage does not provide the isolation features we are discussing here. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄
Re: Limiting the power of packages
* 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 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. > > That particular app's whitelist presumably includes "share the entire > host filesystem"; the existence of a whitelist doesn't mean the whitelist > isn't large. General-purpose development tools and text editors generally > have larger whitelists than more limited apps, with GNOME Builder at > the extreme of least-confined. The other problem is that the whitelist comes from the application author, so it's like asking a drunk whether they are drunk. > % flatpak --user install flathub org.gnome.gedit > Installing in user: > org.gnome.Platform.Locale/x86_64/3.28 flathub 2823e3d81b74 > org.gnome.gedit/x86_64/stable flathub a03b66681bce > permissions: ipc, wayland, x11 > file access: host, xdg-run/dconf, ~/.config/dconf:ro > > \- this is why it can read arbitrary files > dbus access: ca.desrt.dconf, org.gtk.vfs.* > org.gnome.gedit.Locale/x86_64/stable flathub c2974b37ef08 > Is this ok [y/n]: > > I think the intention is that GUIs like GNOME Software prompt for apps > that need special permissions in a more user-friendly way, something > like how Android handles app permissions, although I don't think that's > actually implemented yet. Yes, I tried this on Fedora 28 before posting, which I consider the reference implementation. There is no security prompt at all. I've also been told in an other context that it is up to the Flatpak repository to vet the permissions requested by the software authors. This model would be closer to what the Debian archive does in practice. > I don't know specifically why gedit has the host file access > permission: it's unnecessary for File->Open and File->Save > As... (e.g. org.gnome.Recipes is a good example of an app that > doesn't, but can still import and export recipes) but presumably some > of gedit's IDE-like features involve opening files other than the one > you directly asked for. I assume it's because gedit creates backup files when saving, and the document portal does not support that.
Re: Limiting the power of packages
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
in every single toe with only one shot.
Re: Limiting the power of packages
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 maintainer scripts - they even wrote a shell script parser, that is not a shell itself. However, I would not try to see this work too much as means of defense against malicious deb packages. This leads to a wrong, non-achievable goal. I see it as a means to provide better quality, predictable system state, and safety against bugs. > Compared > with the security models of iOS or Android, we still have quite a lot of > work to do to make sure (say) my IRC client cannot steal my bank > credentials or (the horror!) vice-versa. ;) :~)
Re: Limiting the power of packages
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 list for 3rd-party-links. What you really want here is a 3rd party non-free bikeshed. Cheers, Thomas Goirand (zigo)
Re: Limiting the power of packages
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, controlled in the >> sources.list file, we could at least restrict what third-party packages >> would do. > > Not just third-party packages: this isolation feature could limit the > damage that could occur from buggy maintainer scripts in Debian's own > scripts too. And prevent stuff like with the bumblebee uninstall disaster because of an added space, for example: rm -rf /usr /share/foo/bar.conf Cheers, Thomas Goirand (zigo)
Re: Limiting the power of packages
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 second sources list for 3rd-party-links. This would not restrict what those packages would do, so it's orthogonal to what we are discussing here. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Limiting the power of packages
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 archive, so adding the features being discussed won't protect users who run external install scripts like these two examples. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#910278: ITP: pygalmesh -- a Python frontend to CGAL's 3D mesh generators
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: pygalmesh Version : 0.2.5 Upstream Author : Nico Schlömer * URL : https://github.com/nschloe/pygalmesh * License : MIT Programming Lang: Python Description : a Python frontend to CGAL's 3D mesh generators pygalmesh makes it easy to create high-quality 3D volume and surface meshes. CGAL offers two different approaches for mesh generation: - Meshes defined implicitly by level sets of functions. - Meshes defined by a set of bounding planes. pygalmesh provides a front-end to the first approach, which has the following advantages and disadvantages: - All boundary points are guaranteed to be in the level set within any specified residual. This results in smooth curved surfaces. - Sharp intersections of subdomains (e.g., in unions or differences of sets) need to be specified manually (via feature edges, see below), which can be tedious. On the other hand, the bounding-plane approach (realized by mshr), has the following properties: - Smooth, curved domains are approximated by a set of bounding planes, resulting in more of less visible edges. - Intersections of domains can be computed automatically, so domain unions etc. have sharp edges where they belong. CGAL (C++) is not so easy to use. pygalmesh helps make it that much more accessible, and complements mshr. Maintained under Debian Science alongside mshr.
Bug#910279: ITP: optimesh -- Mesh optimization, mesh smoothing.
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: optimesh Version : 0.4.3 Upstream Author : Nico Schlömer * URL : optimesh * License : MIT Programming Lang: Python Description : Mesh optimization, mesh smoothing. Several mesh smoothing/optimization methods with one simple interface. optimesh - is fast, - preserves submeshes, - only works for triangular meshes (for now; upvote this issue if you're interested in tetrahedral mesh smoothing), and - supports all mesh formats that meshio can handle. It provides the recommended CVT method (centroidal Voronoi tesselation), but also offers CPT (centroidal patch tesselation) and ODT (optimal Delaunay tesselation). To be maintained under Debian Science alongside Nico's meshio and pygalmesh.
Re: Limiting the power of packages
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. https://seclists.org/fulldisclosure/2018/Sep/53 > (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), they'd split off the sources.list part from the actual package (there're many good ways to do that), and added proper pinning to reduce the attack surface. And they would have talked to the Distros about a proper process of bringing Skype into Distro repos. OTOH, considering the tons of other bugs and design flaws, I'm not really sure whether they're nefarious or incompetent, maybe a mix of both ... > they're trying to make sure security updates for their > packages will be deployed to user's system; this seems like a worthy > goal. But it's a surprise to some users.) The goal is nice, but that's what Distros are for. But it's always the same since aeons: commercial vendors tend to work against the distros. > I don't think it's good enough to say the user shouldn't install > third-party packages. Actually, I do think so (unless the user knows exactly what he does). It's not about proprietary software in general - this can (and is) also handled by Distros. But the Distro (or some other neutral project, that provides an extra repo) is needed as quality gate. > It's not even good enough to say the user should > use flatpaks or snaps instead: not everything can be packaged that > way. Debian's own packages can have equally unwelcome surprises. Haven't really looked deeper into flatpak, but I'm doing a lot with docker and lxc containers. As those proprietary vendors tend to be completely overstrained with the whole concept of package management (no idea why, but I've seen this a thousand times w/ my clients), it seems to be the most pragmatic solution to put everything into strictly isolated containers. Those packages are only few special cases anyways. (for the average end-user I don't see much more candidates besides Skype, but there's still a lot very special business applications each having a petty tiny user base). That way, the vendors could just pick some minimal base system (maybe apline or devuan based) and step by step learn how to use package management, in their own confined microcosmos. At least they wouldn't have to cope w/ many different distros, as long as they haven't understood the whole concept behind (if they did, it would be pretty trivial for them, and we wouldn't need this this discussion). > Imagine a package that accidentally removes /var, but only under > specific conditions. You'd hope that Debian's testing during a release > cycle would catch that, but there's not guarantee it will. (That's a > safety issue more than a security issue.) Did this ever happen ? Why should anybody write such things into a maintainer script in the first place ? > 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. Rebuild flatpak+friends ? Point is: maintainer scripts can do anything they want. What we can (and should) do is doing most things in a purely declarative way - at deployment time, instead of autogenerating mnt scripts or calling predefined functions - so we can concentrate on more careful reviews of the remaining special cases. By the way: at lot of the demand for mnt scripts, IMHO, comes from upstream's bad sw architecture (interestingly, GUI stuff again tends to be the ugliest area). Usually, good packages should be fine with just unpacking some files into proper places. > This could be done, for example, by having each package labelled with > an installation profile, which declares what the package intends to do > upon installation, upgrade, or removal. Who defines these labels ? The packager ? Is there any extra quality gate (before the user) ? > * default: install files in /usr only That's bad enough, if the package is of bad quality or even malicious. Finally, I'd really like to reduce complexity, not introduce even more. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Limiting the power of packages
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 Chrome .deb add to > the APT sources lists and APT accepted signing keys. > A suggestion: we restrict where packages can install files and what > maintainer scripts can do. > This could be done, for example, by having each package labelled with > an installation profile, which declares what the package intends to do > upon installation, upgrade, or removal. > > * default: install files in /usr only > * kernel: install files in /boot, trigger initramfs > * core: can install files anywhere, trigger anything This would be a nice safety feature for users and for us maintainers: I know I won't screw up anybody's system with a font package as I restricted it to /usr/share and /etc/fonts. But I don't think it would solve the problem you pose. Who is going to set the profile? If if is the 3rd party packager, they will just use 'core' and install their APT source (or whatever they want). If it can be specified or overridden by the user at install time, then trying to install Skype with --profile=default will make the installation fail, and the user will just resort to --profile=core. Paride
Bug#910283: ITP: kamcli -- Kamailio Command Line Interface Control Tool
Package: wnpp Severity: wishlist Owner: Victor Seva -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: kamcli Version : 1.1.0 Upstream Author : Daniel-Constantin Mierla * URL : https://github.com/kamailio/kamcli * License : GPL-2+ Programming Lang: Python Description : Kamailio Command Line Interface Control Tool kamcli is aiming at being a modern and extensible alternative to the shell script kamctl. . It requires that jsonrpcs module of Kamailio is loaded and configured to listen on an Unix domain socket or FIFO file. The way to interact with Kamailio has to be set inside kamcli config file (kamcli.ini). -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEjxnK3NQqQtRVY3MMUaCbGM9aUGgFAlu19xIACgkQUaCbGM9a UGjhpA/7BfI64U2WaFHND/z31q/bhnItirxqS9DQi6d/YPjxDBeLjEG2FqWKuKJg 1rBPhnk43zSwTiIT7Yr9taTuUnU18S2S8UM4+bxLLff3lBxf0xztkQABN0DOMAdT hDdsFRJqvZ8L6jKpqHBH+Z8m6ebikKgBI4I5kLUm0w5YG7LkGS9MQ5X47otjnL21 rRvpnFopWsD7GkJRyToCnBGm0AlhBSp4db+838NijJLMiPvmVpyGrnjDJWM5XSlQ Tsf8cZ/6tSDMAPNjt4nEoOYGIBnYIsauw1MzeMwqtyn5Xfx655Tu1VJGzlmi+b9s n5zyhEN2G4XD0rN7sZRUXUT0AVFGP+XMAhYMStApa13uX/ZeXQBXqt+SMLGM7RKt Mj9P4Z5i/gChwbSC62nfGxa+2c0XtP9o32D078OKacQPDyf7yvzfOEEkI7Cb0Uly rlPLQPU5v19zLVPDMTcLOQRdQa1lo01Lk8KEqhpnBlWFpkjyopCQtYL1sezT3kuE F7z85oL9EBz1bovDAW7DWotrWdZEJInNpqyVl7Qt5R+vfiCqI2nwu/xmjcimhDbX Ej5ZKwyXXUaguBljqXQEpGuSstKOJnWOeDk3nbNZ+uSVjdkoCi8LlWtrKch3yNfE Bx7X546AVfuZIynzPsCEGuD7AJJnUyXFV3JuaQweZh/OeaxOClo= =V+22 -END PGP SIGNATURE-
Re: Limiting the power of packages
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 list for 3rd-party-links. We don't need to add anything to dpkg/apt for that - there's a simpler solution: Automatically fetch those packages from the vendor and collect them into our own repo, but run a strict analysis before accepting anything. Rules could be strictly limiting to certain filename patterns, file modes (eg. forbid suid or limit to certain owners), no maintainer scripts, etc, etc. We could either filter out anything suspicious or reject the package completely (maybe even automatically filing upstream bugs :p). Yes, that would have to be customized per-package, but we're only talking about a hand full of packages, anyways. What's really important for me: don't add more complexity on the target apt/deb for these few cases, unless *absolutely* *necessary* By the way: we can put aside the whole Skype issue for the next few month, as it's completely broken and unusable anyways - for several month now. We could reconsider once the Upstream (Microsoft) manages get it at least running w/o segfaulting. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Limiting the power of packages
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
>> example, the Microsoft Skype .deb and the Google Chrome .deb add to
>> the APT sources lists and APT accepted signing keys.
>
>> A suggestion: we restrict where packages can install files and what
>> maintainer scripts can do.
>
>> This could be done, for example, by having each package labelled with
>> an installation profile, which declares what the package intends to do
>> upon installation, upgrade, or removal.
>>
>> * default: install files in /usr only
>> * kernel: install files in /boot, trigger initramfs
>> * core: can install files anywhere, trigger anything
>
> This would be a nice safety feature for users and for us maintainers: I
> know I won't screw up anybody's system with a font package as I
> restricted it to /usr/share and /etc/fonts.
>
> But I don't think it would solve the problem you pose. Who is going to
> set the profile? If if is the 3rd party packager, they will just use
> 'core' and install their APT source (or whatever they want). If it can
> be specified or overridden by the user at install time, then trying to
> install Skype with --profile=default will make the installation fail,
> and the user will just resort to --profile=core.
>
> Paride
Hi all,
other ideas:
- use a sort of restricted shell (or a meta language) for {pre,post}int
scripts and debian/rules: only access to debconf db and its own files
=> So no way to execute a custom script during install.
- remove suid bits unless package is signed by Debian: it means that
there could be 2 different key stores: apt one and dpkg one
My 2 cents...
Xavier
Re: Limiting the power of packages
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), > they'd split off the sources.list part from the actual package (there're > many good ways to do that), and added proper pinning to reduce the > attack surface. > > And they would have talked to the Distros about a proper process of > bringing Skype into Distro repos. > > OTOH, considering the tons of other bugs and design flaws, I'm not > really sure whether they're nefarious or incompetent, maybe a mix of > both ... It's not like Debian provides a way that nicely integrates with the system except by what they are doing. Yes, one could ship a pin to limit to specific packages, but from the point of the vendor there's no threat here: They know what they are going to ship. And from a vendor point of view you actually want to have the agility to rotate the GPG key in use, to switch to a different hosting place, and to ship more packages as required. So it's just that your and the vendor's assumptions mismatch. Ultimately what most users want is something that is kept up-to-date. At the point where they decided that they want (or need) to use a vendor's software, it's not really our business anymore to tell them off. You yield full control to the vendor at that point, just like Debian has full control of your system. If we had a sensible way to report back binary provenance, we could at least call out when a vendor did something nefarious. (Like serving a trojan to a specific user.) But we don't. And to the point of nefavious vs. incompetence: The truth is that most companies employ software engineers to do the packaging. Apart from Linux being a small market for most of this software, it is also something they are not necessarily familiar with or would need to hire some kind of specialist for. I understand that you are in that business. But at the same time most programmers assume that it's just a small matter of programming and it can't be that hard to integrate with another system. They can't really anticipate the bugs. But we at least need to hold them accountable to listening to feedback. > That way, the vendors could just pick some minimal base system (maybe > apline or devuan based) [...] That's also where you lost me, FWIW. Kind regards Philipp Kern
Re: Problem sending my key to keyring.debian.org
On Wed, Oct 3, 2018 at 9:28 AM Joseph Herlant wrote: > > Hi, > > On Tue, Oct 2, 2018 at 6:10 PM Seth Arnold wrote: > > Two thoughts: first, give it another try. I was able to refresh my > > keyring using the debian keyserver a few seconds ago: > > > > $ gpg --refresh-keys --keyserver keyring.debian.org > > gpg: refreshing 229 keys from hkp://keyring.debian.org > > ... > > gpg: new signatures: 160 > > ... > > Ok, so that's really a problem on my end. I've been having this issue > since I started trying to update it yesterday and still have now. > Tried 4 or 5 times during the day, same issue. > Same error while trying to refresh. > Have you succeed? You may debug with, add following line to ~/.gnupg/dirmngr.conf log-file /tmp/dirmngr.log debug-level advanced debug-all then run `gpgconf --kill dirmngr`, send/recv it again, you will see the log in /tmp/tmp/dirmngr.log This method applies to other gpg components. -- Shengjing Zhu
Bug#910290: ITP: schroedinger-maeparser -- parser for the Maestro (.mae) file format
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: schroedinger-maeparser Version : 1.0.1 Upstream Author : Schroedinger * URL : https://github.com/schrodinger/maeparser * License : BSD-like Programming Lang: C++ Description : parser for the Maestro (.mae) file format About to be uploaded to Debichem for team maintenance. The library is a build dependency for rdkit.
Re: Limiting the power of packages
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 is AppArmour. Sadly, AppArmor is not very well suited _for desktop apps_ at the moment. Approaches based on sandboxing + portals seem to be a much better design. Cheers, -- intrigeri
Bug#910294: ITP: python-tld -- Extract the top level domain (TLD) from a given URL
Package: wnpp Severity: wishlist Owner: Sophie Brun * Package name: python-tld Version : 0.9.1 Upstream Author : Artur Barseghyan * URL : https://github.com/barseghyanartur/tld * License : MPL-1.1/GPL-2/LGPL-2.1+ Programming Lang: Python Description : Extract the top level domain (TLD) from a given URL This Python module extracts the top level domain (TLD) from the URL given. It uses the list of TLD names provided by publicsuffix. It's a dependency of wapiti version 3.0.1 I plan to maintain the package in the Debian Python Modules Team.
Bug#910304: ITP: commons-dbcp2 -- Database Connection Pooling Services 2
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: commons-dbcp2 Version : 2.5.0 Upstream Author : Apache Software Foundation * URL : https://commons.apache.org/proper/commons-dbcp/ * License : Apache-2.0 Programming Lang: Java Description : Database Connection Pooling Services 2 The DBCP package provides database connection pooling services. The following features are supported . * DataSource and Driver interfaces to the pool. * Support for arbitrary sources of the underlying Connections. * Integration with arbitrary org.apache.commons.pool.ObjectPool implementations. * Support for Connection validation, expiration, etc. * Support for PreparedStatement pooling. * XML configuration. . This package contains the version 2 series. This package is a new build-dependency of mediathekview.
Re: Problem sending my key to keyring.debian.org
Hi guys, Sorry I was out yesterday, slammed by work & life! :) On Wed, Oct 3, 2018 at 12:19 AM Chris Knadle wrote: > Which Debian branch of GnuPG is this error happening with? > (I assume it's Sid/Unstable). Yes, it's unstable. On Thu, Oct 4, 2018 at 6:23 AM Shengjing Zhu wrote: > Have you succeed? Thanks a lot Shengjing, that was very helpful! :) Thanks to the debug logging I've been able to identify that my issue is actually the known issue referenced in our bug tracker as #870806. trying to enable the ipv6 module didn't work for me (for whatever reason it doesn't load, with no error), but temporarily adding the disable-ipv6 to ~/.gnupg/dirmngr.conf did the trick! It works now. Thanks again! :) Joseph
Re: Sending using my @debian.org in gmail
Hi Simon, On Wed, Oct 3, 2018 at 7:07 PM Simon Quigley wrote: > Ubuntu has some very detailed Gmail-specific documentation, I would > recommend that you grab relevant information from that as well: > https://wiki.ubuntu.com/UbuntuEmail Thanks for the link pretty well explained. I added a note about it in https://wiki.debian.org/MigrateToDDAccount Joseph
Bug#910308: ITP: jiconfont -- API to provide icons generated by any icon font
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: jiconfont Version : 1.0.0 Upstream Author : jiconfont * URL : https://github.com/jIconFont/jiconfont * License : MIT Programming Lang: Java Description : API to provide icons generated by any icon font jIconFont is an API to provide icons generated from any IconFont. These icons can be used in Java GUI toolkits, such as Swing and JavaFX. Create your own icon fonts or use some of the existing ones like Elusive, Entypo, Font Awesome, Google Material Design Icons, Open Iconic or Typicons. This is a new dependency for mediathekview.
Bug#910314: ITP: jiconfont-swing -- jIconFont - Swing support
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: jiconfont-swing Version : 1.0.1 Upstream Author : Cadu Andrade * URL : https://github.com/jIconFont/jiconfont-swing * License : MIT Programming Lang: Java Description : jIconFont - Swing support jIconFont is an API to provide icons generated from any IconFont. This package provides icon support for the Swing Java GUI toolkit.
Bug#910320: ITP: jiconfont-font-awesome -- jIconFont - Font Awesome
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: jiconfont-font-awesome Version : 4.7.0.0 Upstream Author : Cadu Andrade * URL : https://github.com/jIconFont/jiconfont-font_awesome * License : MIT, SIL-OFL 1.1 Programming Lang: Java Description : jIconFont - Font Awesome jIconFont is an API to provide icons generated from any IconFont. These icons can be used in Java GUI toolkits, such as Swing and JavaFX. This package provides support for the Font Awesome icon font.
Re: Limiting the power of packages
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 has done a lot of work there, while Ralf > Treinen and colleagues are analysing maintainer scripts - they > even wrote a shell script parser, that is not a shell itself. Indeed, our goal is to do QA on maintainer script and to detect (possibly) buggy ones, in the sense that they may fail in a unforeseen situation, or do stuff which the script is not supposed to do. One of the difficulties is of course to know what it is supposed to do, and what it must never do. Having a declaration of what the maintainer thinks are the possible effects of a script would certainly help us. In that case we could try to infer the possible effects of a script and check that they do not exceed what is declared. > However, I would not try to see this work too much as means of > defense against malicious deb packages. This leads to a wrong, > non-achievable goal. I see it as a means to provide better > quality, predictable system state, and safety against bugs. yes, safety against a malicious attacker is a completely different league. As Guillem has explained in his mail it is very difficult to achieve due to the presence of many different attack vectors, and their possible interaction. -Ralf.
Re: Limiting the power of packages
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, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Limiting the power of packages
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 inflammatory lightning talk at DebConf9 in Cáceres about that, comparing dpkg against Microsoft Installer. :) MSI solves this quite nicely: packages are collections of relational database tables, each table provides the parameters for an action, and the actions themselves are defined by the core installer (with a plugin interface for custom actions, which noone uses). This means that any package that doesn't use any plugins can be evaluated externally by looking at the table data, and Small Business Server includes a tool to statically check packages for conflicts. 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 If we had control files for these, a lot of maintainer scripts would simply be empty, especially in the base system that would be really helpful for "debootstrap --foreign", where the host system could run the actions in the newly installed system even if the architecture does not match, and we could avoid running services in freshly installed chroots as well. Smaller items: - ldconfig could be a control file as well -- if it's present, we need to run ldconfig. We already have a solution for that with file-based triggers, but this would be also be more transparent for "debootstrap --foreign". - Moving files into new locations would need a table old version; new version; old location; new location When upgrading from a version between the old and new versions, the files need to be moved (this would catch preinst for move, and postinst for aborted-upgrade). - Updates from debconf to files in /etc/default This requires some more thought than I can provide at this late hour. - Installation of new APT sources and keys Having the information as descriptive data will allow filtering and adding constraints during source/key installation, e.g. by keeping keys installed through this mechanism associated with the source installed in the same package, and having packages from the source inherit constraints from the package that provided the source. Ideally, maintainer scripts would be a last-resort option if none of the existing descriptive mechanisms works. Packages using these control files would obviously require a dpkg version that supports them, and we'd also need a mechanism for adding new control files over time. The main difficulty I see is keeping compatibility for upgrades, so stable dpkg can still install packages from unstable. My proposal would be that packages start using "_alternatives" first (which dpkg knows to ignore if it doesn't understand it, it's almost as if someone knew what they were doing back then) together with a maintainer script that makes the alternatives handling conditional on the return code of a query command that checks if dpkg handles the control file internally. Then, a few years later, we transition to "alternatives" as a control file, and no maintainer script. Most packages would probably use dh_alternatives for that anyway. Simon
Re: Limiting the power of packages
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/groups - update-icon-cache and similar - create various symlinks - some directory and file creation in postinst could probably avoided, too Cheers
Work-needing packages report for Oct 5, 2018
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1308 (new: 6) Total number of packages offered up for adoption: 185 (new: 18) Total number of packages requested help for: 57 (new: 2) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: cowsay (#910035), orphaned 3 days ago Description: configurable talking cow Reverse Depends: cowsay-off presentty Installations reported by Popcon: 3216 Bug Report URL: http://bugs.debian.org/910035 le-dico-de-rene-cougnenc (#909850), orphaned 5 days ago Description: the "Dico" by Rene Cougnenc Installations reported by Popcon: 37 Bug Report URL: http://bugs.debian.org/909850 libgroove (#909869), orphaned 5 days ago Description: audio dispatching library Reverse Depends: libgroove-dbg libgroove-dev libgroovefingerprinter-dev libgroovefingerprinter4 libgrooveloudness-dev libgrooveloudness4 libgrooveplayer-dev libgrooveplayer4 node-groove Installations reported by Popcon: 112 Bug Report URL: http://bugs.debian.org/909869 liblaxjson (#909903), orphaned 5 days ago Description: relaxed streaming JSON parser library (development files) Reverse Depends: liblaxjson-dev Installations reported by Popcon: 6 Bug Report URL: http://bugs.debian.org/909903 libsoundio (#909881), orphaned 5 days ago Description: cross platform audio input and output library Reverse Depends: libsoundio-dbg libsoundio-dev Installations reported by Popcon: 24 Bug Report URL: http://bugs.debian.org/909881 xsensors (#909944), orphaned 4 days ago Description: hardware health information viewer Installations reported by Popcon: 1529 Bug Report URL: http://bugs.debian.org/909944 1302 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: fortune-zh (#910181), offered yesterday Reverse Depends: fortune-zh Installations reported by Popcon: 1297 Bug Report URL: http://bugs.debian.org/910181 lua-moses (#910180), offered yesterday Reverse Depends: lua-torch-nn Installations reported by Popcon: 36 Bug Report URL: http://bugs.debian.org/910180 lua-torch-cutorch (#910164), offered yesterday Reverse Depends: libtorch-thc-dev lua-torch-cutorch Installations reported by Popcon: 11 Bug Report URL: http://bugs.debian.org/910164 lua-torch-cwrap (#910179), offered yesterday Reverse Depends: lua-torch-torch7 torch-core-free Installations reported by Popcon: 105 Bug Report URL: http://bugs.debian.org/910179 lua-torch-dok (#910178), offered yesterday Reverse Depends: lua-torch-image torch-core-free Installations reported by Popcon: 42 Bug Report URL: http://bugs.debian.org/910178 lua-torch-graph (#910177), offered yesterday Reverse Depends: lua-torch-nngraph torch-core-free Installations reported by Popcon: 36 Bug Report URL: http://bugs.debian.org/910177 lua-torch-image (#910176), offered yesterday Reverse Depends: torch-core-free Installations reported by Popcon: 33 Bug Report URL: http://bugs.debian.org/910176 lua-torch-nn (#910175), offered yesterday Reverse Depends: libtorch-thnn-dev lua-torch-nn lua-torch-nngraph torch-core-free Installations reported by Popcon: 36 Bug Report URL: http://bugs.debian.org/910175 lua-torch-nngraph (#910174), offered yesterday Reverse Depends: torch-core-free Installations reported by Popcon: 34 Bug Report URL: http://bugs.debian.org/910174 lua-torch-optim (#910173), offered yesterday Reverse Depends: torch-core-free Installations reported by Popcon: 35 Bug Report URL: http://bugs.debian.org/910173 lua-torch-paths (#910172), offered yesterday Reverse Depends: lua-torch-paths-dev lua-torch-sys lua-torch-torch7 torch-core-free Installations reported by Popcon: 54 Bug Report URL: http://bugs.debian.org/910172 lua-torch-sundown (#910171), offered yesterday Reverse Depends: lua-torch-dok torch-core-free Installations reported by Popcon: 44 Bug Report URL: http://bugs.debian.org/910171 lua-torch-sys (#910170), offered yesterday Reverse Depends: lua-torch-image lua-torch-trepl lua-torch-xlua torch-core-free Installations reported by Popcon: 37 Bug Report URL: http://bugs.debian.org/910170 lua-torch-torch7 (#910169), offered yesterday Reverse Depends: libtorch-luat-dev libtorch-th-dev libtorch-thc lib
Re: Limiting the power of packages
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 radar: https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging -- bye, pabs https://wiki.debian.org/PaulWise
