Re: Bug#995189: RFH: isc-dhcp

[Philipp Hahn]

Hello Ansgar,

Am 07.03.23 um 20:26 schrieb Ansgar:

On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:

On Mar 07, Philipp Hahn  wrote:

Is it a good idea to keep it alive for another 2+ years in
Debian-12-Bookworm or should it be removed now?
https://packages.debian.org/source/bookworm/isc-dhcp

>>

I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are
is no obvious replacement: Kea is super complex (and I do not know if it
has all the features) and everything else is too much simple.


Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.


Are you sure the *server* is still maintained? Sadly my quote from 
 got dropped, so here again:



ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC will 
continue providing professional support services for existing subscribers, but 
does not intend to issue any further maintenance releases.


Previously ISC announced EoL *only for client and relay*, but — at least 
for my reading of the above statement ­— they no longer do and *ended 
all of DHCP*. Or do we (Debian) have access to that "professional 
support services" to get future patches we can apply?


Do we do our users a service by keeping that dead horse alive for 
another 2+ years? While being quite stable it had a steady stream of 
security issues: 



Philipp

Re: Bug#995189: RFH: isc-dhcp

[Marco d'Itri]

On Mar 08, Philipp Hahn  wrote:

> Do we do our users a service by keeping that dead horse alive for another 2+
> years? While being quite stable it had a steady stream of security issues:
Yes, unless you know of other implementations with that features set.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#995189: RFH: isc-dhcp

[Santiago Ruano Rincón]

Hi Philipp,

El 08/03/23 a las 10:45, Philipp Hahn escribió:
> Hello Ansgar,
> 
> Am 07.03.23 um 20:26 schrieb Ansgar:
> > On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:
> > > On Mar 07, Philipp Hahn  wrote:
> > > > Is it a good idea to keep it alive for another 2+ years in
> > > > Debian-12-Bookworm or should it be removed now?
> > > > https://packages.debian.org/source/bookworm/isc-dhcp
> >>
> > > I do not think that it should be removed at this point, since there is
> > > a need for the complex features that isc-dhcpd can provide and there are
> > > is no obvious replacement: Kea is super complex (and I do not know if it
> > > has all the features) and everything else is too much simple.
> > 
> > Only the client and relay are no longer maintained upstream. The server
> > is still maintained and there is no need to drop it from Debian.
> 
> Are you sure the *server* is still maintained? Sadly my quote from
>  got dropped, so here again:

From README:

RELEASE STATUS

Version 4.4.3-P1 is a maintenance release of the DHCP client, relay and
server. It is the final release for the client and relay components,
which have reached end-of-life and will no longer be maintained.


> 
> > ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC 
> > will continue providing professional support services for existing 
> > subscribers, but does not intend to issue any further maintenance releases.

You can still read an equivalent sentence from the dhcp upstream url:

"DHCP is available for free download under the terms of the MPL 2.0
license. The client and relay portions of ISC DHCP are no longer
maintained."

> 
> Previously ISC announced EoL *only for client and relay*, but — at least for
> my reading of the above statement ­— they no longer do and *ended all of
> DHCP*. Or do we (Debian) have access to that "professional support services"
> to get future patches we can apply?
> 
> Do we do our users a service by keeping that dead horse alive for another 2+
> years? While being quite stable it had a steady stream of security issues:
> 
> 
> Philipp
> 

 -- Santiago


signature.asc
Description: PGP signature

Re: Bug#995189: RFH: isc-dhcp

[Philipp Hahn]

Hello Santiago,

Am 08.03.23 um 11:17 schrieb Santiago Ruano Rincón:

El 08/03/23 a las 10:45, Philipp Hahn escribió:

Am 07.03.23 um 20:26 schrieb Ansgar:

On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:

On Mar 07, Philipp Hahn  wrote:

Is it a good idea to keep it alive for another 2+ years in
Debian-12-Bookworm or should it be removed now?
https://packages.debian.org/source/bookworm/isc-dhcp


I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are
is no obvious replacement: Kea is super complex (and I do not know if it
has all the features) and everything else is too much simple.


Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.


Are you sure the *server* is still maintained? Sadly my quote from
 got dropped, so here again:


 From README:

 RELEASE STATUS

Version 4.4.3-P1 is a maintenance release of the DHCP client, relay and
server. It is the final release for the client and relay components,
which have reached end-of-life and will no longer be maintained.


That does not help: they did a maintenance release in the past. So 
*past* issues were addressed. Excellent!

But what happens in the future? Will we get *future* updates:
- client: No, as officially EoL
- relay: No, as officially EoL
- server: through "providing professional support services"


ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC will 
continue providing professional support services for existing subscribers, but 
does not intend to issue any further maintenance releases.


You can still read an equivalent sentence from the dhcp upstream url:

"DHCP is available for free download under the terms of the MPL 2.0
license. The client and relay portions of ISC DHCP are no longer
maintained."


Again does not help: I can even still download older releases with 
unfixed issues.
But I want to know if I should still base my environment/work on 
ISC-DHCP-server in the future, that is: Will it be maintained in the 
future and will we get patches for security issues?


Do you "Debian ISC DHCP Maintainers " have 
enough expertise and willingness to maintain it for another 2+ years 
("without" support from upstream ISC)?


Philipp

Re: Bug#995189: RFH: isc-dhcp

[Marc Haber]

On Tue, 07 Mar 2023 20:26:20 +0100, Ansgar  wrote:
>Only the client and relay are no longer maintained upstream. The server
>is still maintained and there is no need to drop it from Debian.

They pulled the plug on relay and client from now to immediately, with
no obvious replacement on the relay side, and then announced EOL for
the server for end of 2022, leaving the world without the reference
implementation.

This is really bad.

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#1032520: ITP: libthreadar -- C++ classes for manipulating threads

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libthreadar
  Version : 2.4.0
  Upstream Author : Denis Corbin
* URL : https://sourceforge.net/projects/libthreadar/
* License : LGPL v3+
  Programming Lang: C++
  Description : C++ classes for manipulating threads


 Libthreadar is a C++ library providing an abstracted set of C++ *classes* to
 manipulate threads in a very simple and efficient way from your C++ code.
 .
 It also handles exceptions thrown from a thread and propagated to another one,
 when the later is calling the thread::join() method. This let one manage
 exceptions as simply as it is in C++ single threaded context.
 .
 Additionally, all the related objects around multi-threading (mutex, semaphore,
 ...) are provided, under easy to use and independent C++ classes.  Other more
 advanced classes ease the information exchange between threads like scattering
 and gathering a collection of objects between many threads, or asynchonous
 buffered information exchanges between two threads.
 .
 libthreadar allows the dar package to provide multithreaded encryption,
 compression, and remote repository access.

Re: Bug#995189: RFH: isc-dhcp

[Santiago Ruano Rincón]

El 08/03/23 a las 11:37, Philipp Hahn escribió:
> Hello Santiago,
> 
> Am 08.03.23 um 11:17 schrieb Santiago Ruano Rincón:
> > El 08/03/23 a las 10:45, Philipp Hahn escribió:
> > > Am 07.03.23 um 20:26 schrieb Ansgar:
> > > > On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:
> > > > > On Mar 07, Philipp Hahn  wrote:
> > > > > > Is it a good idea to keep it alive for another 2+ years in
> > > > > > Debian-12-Bookworm or should it be removed now?
> > > > > > https://packages.debian.org/source/bookworm/isc-dhcp
> > > > > 
> > > > > I do not think that it should be removed at this point, since there is
> > > > > a need for the complex features that isc-dhcpd can provide and there 
> > > > > are
> > > > > is no obvious replacement: Kea is super complex (and I do not know if 
> > > > > it
> > > > > has all the features) and everything else is too much simple.
> > > > 
> > > > Only the client and relay are no longer maintained upstream. The server
> > > > is still maintained and there is no need to drop it from Debian.
> > > 
> > > Are you sure the *server* is still maintained? Sadly my quote from
> > >  got dropped, so here again:
> > 
> >  From README:
> > 
> >  RELEASE STATUS
> > 
> > Version 4.4.3-P1 is a maintenance release of the DHCP client, relay and
> > server. It is the final release for the client and relay components,
> > which have reached end-of-life and will no longer be maintained.
> 
> That does not help: they did a maintenance release in the past. So *past*
> issues were addressed. Excellent!
> But what happens in the future? Will we get *future* updates:
> - client: No, as officially EoL
> - relay: No, as officially EoL
> - server: through "providing professional support services"

OK, I see your point. And I must said I missed this:
https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
https://www.isc.org/blogs/isc-dhcp-eol/

> 
> > > > ISC has announced the end of life for ISC DHCP as of the end of 2022. 
> > > > ISC will continue providing professional support services for existing 
> > > > subscribers, but does not intend to issue any further maintenance 
> > > > releases.
> > 
> > You can still read an equivalent sentence from the dhcp upstream url:
> > 
> > "DHCP is available for free download under the terms of the MPL 2.0
> > license. The client and relay portions of ISC DHCP are no longer
> > maintained."
> 
> Again does not help: I can even still download older releases with unfixed
> issues.
> But I want to know if I should still base my environment/work on
> ISC-DHCP-server in the future, that is: Will it be maintained in the future
> and will we get patches for security issues?

"... If we become aware of a significant security vulnerability, we
might make an exception to this (no future maintenance versions), but it
is our intention to cease actively maintaining this codebase."

It is clear that users should migrate. But it is difficult to find the
same set of features, as already said in this thread.

> 
> Do you "Debian ISC DHCP Maintainers " have
> enough expertise and willingness to maintain it for another 2+ years
> ("without" support from upstream ISC)?

No, sorry. At least not me, without upstream support.

> 
> Philipp
> 

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Unlock LUKS with login/password

[Alexey Kuznetsov]

Hello!

I have an idea about how modern linux should work with encrypted LUKS
partitions.

Right now on a system encrypted with LUKS, the first prompt you'll see is a
grub passphrase to unlock the device, after OS boot you see a second prompt
for login/password. This looks redundant.

How about bypassing the second prompt and allowing grub to handle all
security prompts including the login/password and unlocking the LUKS at the
same time? It can be done with few steps:

1) grub can ask for a login/password, then MD5 the text and unlock the LUKS
device using this MD5 passphrase: md5(login+password) or using a simple
plain(login+password) string.

2) grub passing this information (login/password) to the kernel.

3) Kernel boots and passing (or password manager service, which can be part
of systemd) reads that data from kernel (/proc/cmdline) and rewrites it
(hide for security reasons).

4) password manager (systemd service) makes login manager (gdm) auto login
with provided data and unlocking session (gnome) keyring.

5) if the user updates the password (passwd, chpasswd), then the password
manager updates LUKS corresponding slot with md5(login+password) or
plain(login+password) passphrase.

Since LUKS1 supports 8 keys, we can support only 8 logins which can open a
drive and automatically login to the system. Also password manager has to
associate every user (UID) with LUKS device UUID and slot number for simple
key updates.Another option: we can use one SLOT0 or masterkey with a
different technique for encrypting keys and storing all users in the
encrypted list on ESP partition, this option has no user count limits.

I'm using full disk encryption (including /boot), except the ESP
(/boot/efi) partition for grub.img and other EFI binaries).

Theoretically it can work with legacy grub (stage2 compiled using modules
and grub.cfg (right?) which can be used to specify how we should unlock the
device using passphrase or login/password) and the EFI option can read all
configs from grub.cfg.

This is major changes to the linux password management. Can it be improved
and proposed as standard?

-- AK

Re: Unlock LUKS with login/password

[Adrien CLERC]

Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS 
partitions.


Hi,

I'm using LUKS for a long time on both my personal (desktop) and 
professional (laptop) computers. Since they are single user (me), I use 
autologin in the display manager, lightdm in my case. Because there is 
only one slot configured in LUKS, I'm sure this is me, so lightdm can 
autologin safely.


However, you are proposing to solve the case for multiple user 
computers. In that case, I would think about a much simpler design:


- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a 
root user can update the map "slot -> user".


Adrien

Re: Unlock LUKS with login/password

[Alexey Kuznetsov]

On Wed, Mar 8, 2023 at 7:08 PM Agathe Porte  wrote:

> Hi Alexey,
>
> 2023-03-08 16:45 CET, Alexey Kuznetsov:
> > Right now on a system encrypted with LUKS, the first prompt you'll see
> is a
> > grub passphrase to unlock the device, after OS boot you see a second
> prompt
> > for login/password. This looks redundant.
> >
> > How about bypassing the second prompt and allowing grub to handle all
> > security prompts including the login/password and unlocking the LUKS at
> the
> > same time?
>
> I disable the login password by connecting my user automatically on my
> LUKS setup. It is a few clicks away in most DEs I would guess.
>
> Did you consider this instead of implementing what you propose?
>
> Bests,
>
> Agathe.
>

Yes I did. I did the same on my machine. I only type passpharse and initrd
have luks-key script, and gdm has autologin. But another notebook with LUKS
setup has multiple users, so autologin will not work. This is not about
autologin. This is about unlocking your machine LUKS with only
login/password without having an additional passphrase to remember.

Re: Unlock LUKS with login/password

[Alexey Kuznetsov]

On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC  wrote:

> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
>
> Hello!
>
> I have an idea about how modern linux should work with encrypted LUKS
> partitions.
>
> Hi,
>
> I'm using LUKS for a long time on both my personal (desktop) and
> professional (laptop) computers. Since they are single user (me), I use
> autologin in the display manager, lightdm in my case. Because there is only
> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin
> safely.
>
> However, you are proposing to solve the case for multiple user computers.
> In that case, I would think about a much simpler design:
>
> - Remember which slot was used to unlock the LUKS root partition
>
> - Make a map with slot -> user to autologin
>
> - Autologin that user on boot
>
> No more passing password, no more password update headache. But only a
> root user can update the map "slot -> user".
>
> Adrien
>
Right. But you still have to remember passpharse and your main account
password. This is not about autologin. This is about unlocking your machine
LUKS with only login/password without having an additional passphrase to
remember.

Re: Unlock LUKS with login/password

[Agathe Porte]

Hi Alexey,

2023-03-08 16:45 CET, Alexey Kuznetsov:
> Right now on a system encrypted with LUKS, the first prompt you'll see is a
> grub passphrase to unlock the device, after OS boot you see a second prompt
> for login/password. This looks redundant.
>
> How about bypassing the second prompt and allowing grub to handle all
> security prompts including the login/password and unlocking the LUKS at the
> same time?

I disable the login password by connecting my user automatically on my
LUKS setup. It is a few clicks away in most DEs I would guess.

Did you consider this instead of implementing what you propose?

Bests,

Agathe.

Re: Unlock LUKS with login/password

[Arnaud Ferraris]

Le 08/03/2023 à 17:11, Adrien CLERC a écrit :

Hello,


Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS 
partitions.


Hi,

I'm using LUKS for a long time on both my personal (desktop) and 
professional (laptop) computers. Since they are single user (me), I 
use autologin in the display manager, lightdm in my case. Because 
there is only one slot configured in LUKS, I'm sure this is me, so 
lightdm can autologin safely.


However, you are proposing to solve the case for multiple user 
computers. In that case, I would think about a much simpler design:


- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a 
root user can update the map "slot -> user".




The issue with this approach is that you still need to enter a password 
for session keyrings (such as gnome-keyring).
Ideally, the LUKS password would be forwarded to PAM (and automatically 
reused for logging in *and* unlocking the session keyring)


The issue is that the system (often plymouth on desktop/laptop setups) 
would then need to:

* unlock the filesystem
* initialize PAM straight away
* check the user password
* raise an error if either of the above fails, potentially locking the 
filesystem again if the password/encryption key is valid but does not 
match the selected user


Overall a nice idea, but not so simple to implement properly ;)

Cheers,
Arnaud


Adrien

Bug#1032524: ITP: golang-github-gitleaks-go-gitdiff -- Go library for parsing and applying patches created by Git

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-gitleaks-go-gitdiff
  Version : 0.8.0-1
  Upstream Author : Gitleaks
* URL : https://github.com/gitleaks/go-gitdiff
* License : Expat
  Programming Lang: Go
  Description : Go library for parsing and applying patches created by Git

 go-gitdiff is a Go library for parsing and applying patches generated by
 git diff, git show, and git format-patch.  It can also parse and apply
 unified diffs generated by the standard diff tool.
 .
 It supports standard line-oriented text patches and Git binary patches,
 and aims to parse anything accepted by the git apply command.

Reason for packaging: A dependency of gitleaks

Bug#1032527: ITP: golang-github-bep-lazycache -- Thread-safe in-memory LRU cache with non-blocking cache priming on cache misses (Go library)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-bep-lazycache
  Version : 0.2.0-1
  Upstream Author : Bjørn Erik Pedersen
* URL : https://github.com/bep/lazycache
* License : Expat
  Programming Lang: Go
  Description : Thread-safe in-memory LRU cache with non-blocking cache 
priming on cache misses (Go library)

 Lazycache is a simple thread safe in-memory LRU cache.  Under the hood
 it leverages the great simpleru package in golang-lru, with its exellent
 performance.  One big difference between golang-lru and this library is
 the GetOrCreate method, which provides:
 .
  * Non-blocking cache priming on cache misses.
  * A guarantee that the prime function is only called once for a given key.
  * The cache's RWMutex is not locked during the execution of the prime
function, which should make it easier to reason about potential deadlocks.
 .
 Other notable features:
 .
  * The API is generic
  * The cache can be resized while running.
  * When the number of entries overflows the defined cache size, the
least recently used item gets discarded (LRU).


Reason for packaging: Needed by hugo (>= 0.111.0)

Re: Unlock LUKS with login/password

[Marco d'Itri]

On Mar 08, Alexey Kuznetsov  wrote:

> 1) grub can ask for a login/password, then MD5 the text and unlock the LUKS
Forget about this part: encrypted /boot/ is pointless from a security 
point of view and this complexity does not belong in the boot loader.

Once you accept this then you will end up with a design very similar to 
https://www.freedesktop.org/wiki/Specifications/login-unlock/ .

So you would need to implement having Plymouth or whatever else storing 
the credentials in the kernel keyring and then probably a PAM module 
that will make them available to the rest of the stack (notably 
pam_gnome_keyring).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1032535: ITP: golang-github-hashicorp-golang-lru-v2 -- Golang LRU cache (v2 with support for generics)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-hashicorp-golang-lru
  Version : 2.0.1-1
  Upstream Author : HashiCorp, Inc.
* URL : https://github.com/hashicorp/golang-lru
* License : MPL-2.0
  Programming Lang: Go
  Description : Golang LRU cache (v2 with support for generics)

 This provides the lru package which implements a fixed-size thread-safe LRU
 cache.  It is based on the cache in Groupcache.  v2 adds support for generics.


Reason for packaging: Needed by golang-github-bep-lazycache(-dev), which in turn
  is needed by hugo (>= 0.111.0).

Re: Bug#995189: RFH: isc-dhcp

[Ansgar]

Hi,

On Wed, 2023-03-08 at 10:45 +0100, Philipp Hahn wrote:
> Are you sure the *server* is still maintained? Sadly my quote from 
>  got dropped, so here again:
> 
> > ISC has announced the end of life for ISC DHCP as of the end of
> > 2022. ISC will continue providing professional support services for
> > existing subscribers, but does not intend to issue any further
> > maintenance releases.
> 
> Previously ISC announced EoL *only for client and relay*, but — at
> least  for my reading of the above statement ­— they no longer do and
> *ended all of DHCP*.

No, I missed that and only read the parts where upstream said client
and relay is no longer supported.  I now checked again and [1] looks
clear enough: the title is "ISC DHCP Server has reached EOL" (it
mentions the earlier EOL for client and relay at the end).

  [1]: https://www.isc.org/blogs/isc-dhcp-eol/

> Do we do our users a service by keeping that dead horse alive for 
> another 2+ years?

I still think it is too late for major changes for Debian 12/bookworm.

Ansgar

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

That is also the main reason why I do not use automatic login. I need
to enter the password anyway.

Unfortunately, the same is true for smartcard login. An OpenPGP
smartcard would be perfect for both login (including SSH public key
auth) and unlocking the keyring, even better than a password, but that
has not been implemented.

Regards

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

Can you explain or refer to literature why encrypted /boot is
pointless?

Regards

PS: Let's for now ignore non-security benefits, e.g. that encrypted
/boot means that you do not have to decide on the size of your /boot
partition.


signature.asc
Description: This is a digitally signed message part