Discussion:
Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?
(too old to reply)
László Böszörményi (GCS)
2016-03-17 09:30:03 UTC
Permalink
Raw Message
Hi,
I'm reporting against linux-patch-grsecurity2 package but actually I
think it should be reassigned to ftp.debian.org soon. This package is
severely obsolete, and is somehow deprecated by the fact that a
linux-grsec source package now exists, and builds binaries for i386 and
amd64 (with more architectures certainly possible).
It seems linux-grsec will remain i386 and amd64 only. But more
important that's not suitable for a stable release. Filed by its
maintainer, Yves-Alexis. The patch itself can be updated more easily
with point releases and users may compile and test their updated
kernels before using it. For me this gives more trust in the package,
even if it needs more attention from time to time.
I can certainly let you request the removal, or will handle it myself at
one point, unless you really want to keep it and have it updated.
Sure, I've failed big to keep it up-to-date. But I would like to keep
this fresh in the archive. Hope upstream will release testing kernels
every now and then.

Regards,
Laszlo/GCS
Yves-Alexis Perez
2016-03-17 13:10:02 UTC
Permalink
Raw Message
Hi,
 It seems linux-grsec will remain i386 and amd64 only.
There's no reason to, actually. It's just that right now I don't have a way to
test on other architectures, so I prefer keeping it that way. But if someone
steps to to maintain it I'm all open.
But more
important that's not suitable for a stable release. Filed by its
maintainer, Yves-Alexis.
Well, uploading new Linux major version to stable looks indeed not trivial,
(thus my filing of #810506), but ultimately it's the RT's call.
The patch itself can be updated more easily
with point releases and users may compile and test their updated
kernels before using it. For me this gives more trust in the package,
even if it needs more attention from time to time.
Well, I'm not sure how much sense that make. Do you intend to ship in stable a
patch completely unrelated to the current kernel and just follow the test
kernel and ship it pristine?
I can certainly let you request the removal, or will handle it myself at
one point, unless you really want to keep it and have it updated.
 Sure, I've failed big to keep it up-to-date. But I would like to keep
this fresh in the archive. Hope upstream will release testing kernels
every now and then.
I'm not sure what you mean here.
--
Yves-Alexis
László Böszörményi (GCS)
2016-03-17 13:30:03 UTC
Permalink
Raw Message
Post by Yves-Alexis Perez
Post by László Böszörményi (GCS)
It seems linux-grsec will remain i386 and amd64 only.
There's no reason to, actually. It's just that right now I don't have a way to
test on other architectures, so I prefer keeping it that way. But if someone
steps to to maintain it I'm all open.
Ah, OK. That makes sense.
Post by Yves-Alexis Perez
Post by László Böszörményi (GCS)
But more
important that's not suitable for a stable release. Filed by its
maintainer, Yves-Alexis.
Well, uploading new Linux major version to stable looks indeed not trivial,
(thus my filing of #810506), but ultimately it's the RT's call.
I mean can you remain in sync with kernel updates (security updates
only) in stable?
Post by Yves-Alexis Perez
Post by László Böszörményi (GCS)
The patch itself can be updated more easily
with point releases and users may compile and test their updated
kernels before using it. For me this gives more trust in the package,
even if it needs more attention from time to time.
Well, I'm not sure how much sense that make. Do you intend to ship in stable a
patch completely unrelated to the current kernel and just follow the test
kernel and ship it pristine?
It's better to write in detail about my point of view. With the patch
only I would target more experienced users that can and do compile
their kernels. The plan is to have two kind of patches shipped in the
package. One tracking the stable release kernel as close as possible
(security updates only). The second is to add the latest test patch
say, every six months. This can give users a time to follow upstream
kernel development while have the up-to-date testing patch on top of
it. OK, they will need to compile and use their own kernels - but this
also gives more flexibility to them as they can choose which feature
of grsecurity to enable + use.
With a packaged binary kernel you don't have the freedom to choose the
options and harder to get it included in a stable release. Especially
if it's maintained and tested by multiple maintainers to support
several architectures and not just i386 and amd64.
Post by Yves-Alexis Perez
Post by László Böszörményi (GCS)
I can certainly let you request the removal, or will handle it myself at
one point, unless you really want to keep it and have it updated.
Sure, I've failed big to keep it up-to-date. But I would like to keep
this fresh in the archive. Hope upstream will release testing kernels
every now and then.
I'm not sure what you mean here.
I would like to keep Sid updated and provide updated patches for
stable kernel packages. For this I need upstream to release testing
patches in a timely manner. But as mentioned above, I think six months
updates may be enough for advanced users. You get new features while
not compile a new kernel every second day. This seems to be a good
balance.

Hope this is more clear now.
Laszlo/GCS
Yves-Alexis Perez
2016-03-17 16:20:02 UTC
Permalink
Raw Message
Post by Yves-Alexis Perez
Post by Yves-Alexis Perez
Well, uploading new Linux major version to stable looks indeed not
trivial,
Post by Yves-Alexis Perez
(thus my filing of #810506), but ultimately it's the RT's call.
 I mean can you remain in sync with kernel updates (security updates
only) in stable?
No, I can't guarantee that, considering the current grsecurity release model.
That's why I'm asking the RT about new Linux major versions in stable.
Post by Yves-Alexis Perez
Post by Yves-Alexis Perez
  The patch itself can be updated more easily
with point releases and users may compile and test their updated
kernels before using it. For me this gives more trust in the package,
even if it needs more attention from time to time.
Well, I'm not sure how much sense that make. Do you intend to ship in
stable a
Post by Yves-Alexis Perez
patch completely unrelated to the current kernel and just follow the test
kernel and ship it pristine?
 It's better to write in detail about my point of view. With the patch
only I would target more experienced users that can and do compile
their kernels. The plan is to have two kind of patches shipped in the
package. One tracking the stable release kernel as close as possible
(security updates only).
I honestly don't know how you'll be able to do that. The test patch only
follows the latest stable version, not previous ones or LTS, and
stable/stable2 patches are restricted.
Post by Yves-Alexis Perez
The second is to add the latest test patch
say, every six months.
And here I don't see the point to have 6 months delay. While it might not be
useful to track *each and every patch*, beeing 6 months late doesn't make any
sense to me.
Post by Yves-Alexis Perez
This can give users a time to follow upstream
kernel development while have the up-to-date testing patch on top of
it. OK, they will need to compile and use their own kernels - but this
also gives more flexibility to them as they can choose which feature
of grsecurity to enable + use.
With a packaged binary kernel you don't have the freedom to choose the
options and harder to get it included in a stable release. Especially
if it's maintained and tested by multiple maintainers to support
several architectures and not just i386 and amd64.
Sure, but I have to admit I prefer getting the patch directly from
grsecurity.net then.
Post by Yves-Alexis Perez
Post by Yves-Alexis Perez
I can certainly let you request the removal, or will handle it myself
at
Post by Yves-Alexis Perez
one point, unless you really want to keep it and have it updated.
  Sure, I've failed big to keep it up-to-date. But I would like to keep
this fresh in the archive. Hope upstream will release testing kernels
every now and then.
I'm not sure what you mean here.
 I would like to keep Sid updated and provide updated patches for
stable kernel packages. For this I need upstream to release testing
patches in a timely manner.
Which is already the case.
Post by Yves-Alexis Perez
But as mentioned above, I think six months
updates may be enough for advanced users. You get new features while
not compile a new kernel every second day. This seems to be a good
balance.
I sure hope people update kernel more often than every six months.
Post by Yves-Alexis Perez
Hope this is more clear now.
Not really, but at least for the initial intent of this bug, yes: you want to
keep the package in the archive :)

Regards,
--
Yves-Alexis
László Böszörményi (GCS)
2017-01-05 19:40:01 UTC
Permalink
Raw Message
Control: severity -1 important
Post by Yves-Alexis Perez
Post by László Böszörményi (GCS)
But as mentioned above, I think six months
updates may be enough for advanced users. You get new features while
not compile a new kernel every second day. This seems to be a good
balance.
I sure hope people update kernel more often than every six months.
Of course, it depends on the machine and the environment. A machine
with direct connection on the internet should be updated frequently. A
machine with a small number of trusted users on an internal LAN may
not be updated daily.
Post by Yves-Alexis Perez
Post by László Böszörményi (GCS)
Hope this is more clear now.
Not really, but at least for the initial intent of this bug, yes: you want to
keep the package in the archive :)
I do. Lowering the severity for now.

Regards,
Laszlo/GCS

Debian Bug Tracking System
2017-01-05 19:40:01 UTC
Permalink
Raw Message
severity -1 important
Bug #810349 [src:linux-patch-grsecurity2] linux-patch-grsecurity2: removal of linux-patch-grsecurity2?
Severity set to 'important' from 'serious'
--
810349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810349
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...