Bug#923216: ITP: python-fingerprint -- Python 2 and 3 library for using ZhianTec fingerprint sensors

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: python-fingerprint
  Version : 1.5
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/bastianraschke/pyfingerprint
* License : D-FSL
  Programming Lang: Python
  Description : Python 2 and 3 library for using ZhianTec fingerprint 
sensors

Python library for using ZhianTec ZFM-20, ZFM-60, ZFM-70 and ZFM-100 
fingerprint sensors (known as "Arduino fingerprint sensor") in Python 3.
Some other models like R302, R303, R305, R306, R307, R551 and FPM10A also work.

This package is a good addition to Debian since there seems no such library. 
Easy to use. The package is no dependency for other packages. I am looking for 
a sponsor.

Regards,
Philipp Meisberger

Bug#923217: ITP: gamewake -- Alarm clock application

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: gamewake
  Version : 3.5.1
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/philippmeisberger/gamewake
* License : D-FSL
  Programming Lang: Object Pascal
  Description : Alarm clock application

Game Wake is a simple to configure virtual alarm clock application. It
provides multiple types of alerts and features both a timer and counter
mode.

This package is a good addition to Debian since there seems no such
application. I often use it. The package is no dependency for other
packages. I am looking for a sponsor.

Regards,
Philipp Meisberger

Bug#923218: ITP: python-rfid -- Python 2 and 3 library for 125kHz RFID readers

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: python-rfid
  Version : 1.4
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/philippmeisberger/pyrfid
* License : D-FSL
  Programming Lang: Python
  Description : Python 2 and 3 library for 125kHz RFID readers

Library for using 125kHz EM4100 protocol RFID readers.

This package is a good addition to Debian since there seems no such
application. I often use it. I build another project "libpam-rfid" based
on this package. I am looking for a sponsor.

Regards,
Philipp Meisberger

Bug#923220: ITP: arduino-package -- Utility for creating Arduino Debian packages

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: arduino-package
  Version : 1.0
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/philippmeisberger/arduino-package
* License : D-FSL
  Programming Lang: Shell
  Description : Utility for creating Arduino Debian packages

This package provides the capability to build a Debian package from an Arduino 
binary distribution by running make-arduinopkg . Download 
the archive file from https://www.arduino.cc

This package is a good addition to Debian since there seems no such 
application. I often use it. The package is no dependency for other packages. I 
am looking for a sponsor.

Regards,
Philipp Meisberger

Bug#923219: ITP: eclipse-package -- Utility for creating Eclipse Debian packages

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: eclipse-package
  Version : 1.0
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/philippmeisberger/eclipse-package
* License : D-FSL
  Programming Lang: Shell
  Description : Utility for creating Eclipse Debian packages

This package provides the capability to build a Debian package from an Eclipse 
binary distribution by running make-eclipsepkg . Download 
the archive file from https://www.eclipse.org/downloads/eclipse-packages/

This package is a good addition to Debian since there seems no such 
application. I often use it. The package is no dependency for other packages. I 
am looking for a sponsor.

Regards,
Philipp Meisberger

Bug#923221: ITP: libpam-fingerprint -- Pluggable Authentication Module for fingerprint authentication

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: libpam-fingerprint
  Version : 1.5
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/philippmeisberger/pam-fingerprint
* License : D-FSL
  Programming Lang: Python
  Description : Pluggable Authentication Module for fingerprint 
authentication

This module provides biomtric fingerprint authentication. Supported sensors are 
ZhianTec ZFM-20, ZFM-60, ZFM-70 and ZFM-100. Other models like R302, R303, 
R305, R306, R307, R551 and FPM10A also work.

This package is a good addition to Debian since there seems no such package. 
Easy to configure. The package is no dependency for other packages. I am 
looking for a sponsor.

Regards,
Philipp Meisberger

Re: FYI/RFC: early-rng-init-tools

[Andy Simpkins]

On 24/02/2019 20:00, Philipp Kern wrote:

On 2/24/2019 8:52 PM, Thorsten Glaser wrote:

In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during boot; a
message “random: crng init done” would appear, and boot would
continue.

This is a well-known problem, and there are several bugs about
this; new in buster/sid compared to stretch is that it also
blocks urandom reads (I was first hit in the tomcat init script
from this). This is especially noticeable if you use a sysvinit
non-parallel boot, but I’m sure it also affects all others.

FTR this is supposedly fixed on the main architectures featuring an RNG
in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which Ben
announced on this list[1] earlier this month.


Be aware RANDOM_TRUST_CPU depends on: |CONFIG_X86 
 || CONFIG_S390 
 || CONFIG_PPC 
|


I should have thanked Ben for turning this on sooner, in the mean time I 
am preparing email to list for other architectures (Mainly ARM at the 
moment I admit)


/Andy

Bug#923227: ITP: libpam-rfid -- Pluggable Authentication Module for hardware authentication via RFID

[Philipp Meisberger]

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: libpam-rfid
  Version : 1.4
  Upstream Author : Philipp Meisberger 
* URL : https://github.com/philippmeisberger/pam-rfid
* License : D-FSL
  Programming Lang: Python
  Description : Pluggable Authentication Module for hardware authentication 
via RFID

A 125kHz UART compatible RFID reader is required to use this module. The reader 
must be compatible with the EM4100 protocol. PAM RFID was developed with the 
RDM6300 RFID reader.

This package is a good addition to Debian since there seems no such package. 
Easy to configure. The package is no dependency for other packages. I am 
looking for a sponsor.

Regards,
Philipp Meisberger

Re: Bug#923221: ITP: libpam-fingerprint -- Pluggable Authentication Module for fingerprint authentication

[Adam D. Barratt]

On 2019-02-25 08:20, Philipp Meisberger wrote:

Package: wnpp
Severity: wishlist
Owner: Philipp Meisberger 

* Package name: libpam-fingerprint
  Version : 1.5
  Upstream Author : Philipp Meisberger 
* URL : 
https://github.com/philippmeisberger/pam-fingerprint

* License : D-FSL
  Programming Lang: Python
  Description : Pluggable Authentication Module for fingerprint
authentication

This module provides biomtric fingerprint authentication. Supported
sensors are ZhianTec ZFM-20, ZFM-60, ZFM-70 and ZFM-100. Other models
like R302, R303, R305, R306, R307, R551 and FPM10A also work.

This package is a good addition to Debian since there seems no such
package.


Are https://packages.debian.org/sid/libfprint0 and 
https://packages.debian.org/unstable/libpam-fprintd not suitable?


Regards,

Adam

Re: Bug#923221: ITP: libpam-fingerprint -- Pluggable Authentication Module for fingerprint authentication

[Philipp Meisberger]

Poorly libpam-fprintd is not suitable as libfprint0 seems to support
ZhianTec fingerprint sensors. libpam-fingerprint is especially for those
sensors. I see it would be more precise to use "Pluggable Authentication
Module for ZhianTec fingerprint sensors" as description and name the
package "libpam-fingerprint-zfm".

Regards,
Philipp

Am 25.02.19 um 10:30 schrieb Adam D. Barratt:
> On 2019-02-25 08:20, Philipp Meisberger wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Philipp Meisberger 
>>
>> * Package name    : libpam-fingerprint
>>   Version : 1.5
>>   Upstream Author : Philipp Meisberger 
>> * URL : https://github.com/philippmeisberger/pam-fingerprint
>> * License : D-FSL
>>   Programming Lang: Python
>>   Description : Pluggable Authentication Module for fingerprint
>> authentication
>>
>> This module provides biomtric fingerprint authentication. Supported
>> sensors are ZhianTec ZFM-20, ZFM-60, ZFM-70 and ZFM-100. Other models
>> like R302, R303, R305, R306, R307, R551 and FPM10A also work.
>>
>> This package is a good addition to Debian since there seems no such
>> package.
> 
> Are https://packages.debian.org/sid/libfprint0 and
> https://packages.debian.org/unstable/libpam-fprintd not suitable?
> 
> Regards,
> 
> Adam



signature.asc
Description: OpenPGP digital signature

Ważne pytanie

[Agencja Interaktywna]

Dzień dobry, 

 chcielibyśmy przesłać niezobowiązującą 
propozycję dotyczącą wykonania przez nas nowej *Strony* lub *Sklepu* 
internetowego dla Państwa firmy. 

 Zwracamy się z prośbą o 
odpowiedź: *TAK *na ten adres e-mail.

 _ 

 Pozdrawiamy

Salsa CI news

[Inaki Malerba]

Hi everyone !

On behalf of the Salsa CI Team I'm pleased to announce some of the
changes we've been working on this weekend. We don't have an official
mailing list, so please excuse us if this is not the place for this kind
of announcements.

Making the most of the fact that some of us are on the same city this
week, we spent the weekend on a small sprint.

First of all, this is a small changelog of the things we did and will be
working on the following days:

    * Add ccache to the builds. (Thanks @otto and @xcancerberox-guest). 
Now the builds use gitlab's cache option to store ccache data.

    * Add dpkg build job. Today the only builder available is
git-buildpackage. We'd like to have this finished in the following days.

    * Remove 'build-{release}' jobs. Now the build job is just 'build'
and the pipeline should define the RELEASE variable if you want to build
on a release other than unstable. This also impacts on autopkgtest and
lintian. Please keep your project up to date.

    * Buildlog scanner job was included on the tests stage (Thanks
@hartge-guest)

    * Improvements to allow building with dependencies from experimental
(Thanks @sathieu)

    * Many other improvements.

Thanks to all who contributed with the project!

Following this changes, we simplified the way of including the salsa
pipeline. Please read the README[0] to check this. Some automatic MRs
were generated to the projects that were using the pipeline exactly as
the template, and issues will be opened to those which weren't
straight-forward.

We also introduced a way to monitor the pipeline's usage.
prittiau.debian.net is a simple influxdb + grafana which shows some
stats about the projects using the Salsa CI pipeline. You're welcome to
log in with your salsa account.

If you have any question, you can find us on #salsaci at OFTC.


Have a nice week!


[0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md

-- 
- ina




signature.asc
Description: OpenPGP digital signature

Re: Salsa CI news

[Jonathan Dowland]

On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:

On behalf of the Salsa CI Team I'm pleased to announce some of the
changes we've been working on this weekend. We don't have an official
mailing list, so please excuse us if this is not the place for this
kind of announcements.


Thanks for sharing! Personally I think you could consider using
debian-devel-annou...@lists.debian.org (but others may disagree)

Re: Salsa CI news

[Roberto C . Sánchez]

On Mon, Feb 25, 2019 at 02:44:22PM +, Jonathan Dowland wrote:
> On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:
> > On behalf of the Salsa CI Team I'm pleased to announce some of the
> > changes we've been working on this weekend. We don't have an official
> > mailing list, so please excuse us if this is not the place for this
> > kind of announcements.
> 
> Thanks for sharing! Personally I think you could consider using
> debian-devel-annou...@lists.debian.org (but others may disagree)
> 
At the very least make sure the publicity team knows so it makes it into
the next Debian Project News issue.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: FYI/RFC: early-rng-init-tools

[Ben Hutchings]

On Sun, 2019-02-24 at 20:10 +, Thorsten Glaser wrote:
> Hi Philipp,
> 
> >FTR this is supposedly fixed on the main architectures featuring an
> RNG
> >in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which
> Ben
> 
> that’s what I referred to by…
> 
> >>• it does not use/add CPU RNG output where present
> >>  ‣ though Linux can now do that itself, some command-line flag…
> 
> … but that only helps if the CPU has such instructions,
[...]

Indeed, on x86 this requires the RDRAND instruction which Intel
introduced in 2011 (Ivy Bridge core) and AMD only implemented in 2015
(Excavator core).

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates



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

Re: FYI/RFC: early-rng-init-tools

[Ben Hutchings]

On Sun, 2019-02-24 at 19:52 +, Thorsten Glaser wrote:
[...]
> I’ve written something, a linux-any package, that…
> 
> • during postinst, creates a 128-byte random seed file in /
> • updates that in a daily cronjob (using same tool as during
>   boot except with more bits taken from the kernel)
> • updates (the second 64-byte half, from urandom) it on shutdown
> • hooks into initramfs to…
>   – on x86, use “Jytter” (CPU jitter) to try and get some more
> random bytes (not accredited, just written to the pool)
>   – makes it mount the root filesystem, after fsck, read-write
> instead of deferring that to the init scripts (this should
> be safe, though, as initramfs *does* fsck)
>   – after the root filesystem is read-write,
> ‣ reads from the seed file (128 bytes)
> ‣ uses that and a number of other things (to make it differ)…
>   ← md5sum of dmesg

Much of which is the same from boot to boot.  Yes, timestamps will
differ, but the same systems that currently have little entropy
available from interrupts will likely also have very consistent
timestamps during boot.

>   ← 3 random bytes written into initramfs during update-initramfs

That doesn't change from boot to boot.

>   ← the current time

This doesn't add much entropy since RTCs typically have 1 second
resolution and some systems don't even have an RTC.

>   ← a bit of kernel entropy (from AT_RANDOM auxvec, set anyway)

Feeding the kernel RNG output back to itself doesn't add any entropy.

>   ← on x86, Jytter and the TSC
>   to initialise a stretching RNG (arc4random)
> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>   accredit them yet, just remembers the amount written)

How do you determine the number of bytes here?

> ‣ updates the seed file with 128 bytes from the SRNG
> ‣ fsync(2)s and close(2)s the seed file to ensure the next run
>   will be different
> ‣ now tells the kernel X random bits were added, where X is…
>   → the number of bytes written earlier…
>   → times 6 (so we count at best six bits per byte)…
>   → capped at 128*7 bits, to both not overwhelm and because our
> seed is only 128 bytes in size, estimated conservatively
[...]

The major input into the new seed file contents is the old seed file
contents.  You are adding very little entropy on x86, and possibly
almost none on other architectures.

Please reconsider this, as this description sounds dangerously
insecure.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Re: FYI/RFC: early-rng-init-tools

[Michael Stone]

On Mon, Feb 25, 2019 at 03:53:09PM +, Ben Hutchings wrote:

The major input into the new seed file contents is the old seed file
contents.


Yes, I'd just drop the seed file once used, then have a scheduled job 
write a new one at some point in the future if the random quality is
high enough. If you reboot twice in a row the second boot won't get 
seeded, but that's better than a package that introduces potentially 
insecure random seeding by default. Maybe add a non-default option to 
allow seed reuse with a lot of warnings, but don't do it by default.

Bug#923267: ITP: gnome-shell-extension-bluetooth-quick-connect -- GNOME Shell extension to connect paired Bluetooth devices

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: gnome-shell-extension-bluetooth-quick-connect
  Version : (none, git snapshot)
  Upstream Author : Bartosz Jaroszewski
* URL : 
https://extensions.gnome.org/extension/1401/bluetooth-quick-connect/
* License : GPL-2.0-or-later
  Programming Lang: JavaScript
  Description : GNOME Shell extension to connect paired Bluetooth devices

 This GNOME Shell extension adds entries to the shell's System menu
 to provide a quick way to connect and disconnect Bluetooth devices that
 were previously paired with the computer.
 .
 Please note that each user will need to enable the extension manually, for
 example using the gnome-tweaks application.

---

Preliminary packaging at
https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-bluetooth-quick-connect
to be maintained with the GNOME team.

Re: FYI/RFC: early-rng-init-tools

[Ben Hutchings]

On Mon, 2019-02-25 at 18:27 +0200, Uoti Urpala wrote:
> Ben Hutchings wrote:
> > The major input into the new seed file contents is the old seed file
> > contents.  You are adding very little entropy on x86, and possibly
> > almost none on other architectures.
> > 
> > Please reconsider this, as this description sounds dangerously
> > insecure.
> 
> I don't think his goal was to add any significant entropy? I mean,
> using old seed file should be enough by itself, as long as the random
> state was ever initialized to an unpredictable state to create a secret
> seed file, the contents stayed secret, and there is no reuse of the
> same seed file without updating it on disk.

The output of the RNG may well become public, for example in document
UUIDs.  So when estimating the entropy that the new seed file will
provide for the next boot, none of the entropy in the old seed file
should be credited.

Ben.

> At least I didn't read the proposal as relying on that added entropy
> for security.
> 
> 
-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Re: FYI/RFC: early-rng-init-tools

[Thorsten Glaser]

Ben Hutchings dixit:

>> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>>   accredit them yet, just remembers the amount written)
>
>How do you determine the number of bytes here?

32 + arc4random_uniform(256 - 32 + 1)

[…]
>The major input into the new seed file contents is the old seed file
>contents.  You are adding very little entropy on x86, and possibly
>almost none on other architectures.

This is during early boot, where there’s almost no entropy
available yet. This step, while having taken up a lot of
explanation, is mostly to ensure that the next seed differs
from the previous one.

The thing you missed is this:

>>• updates that in a daily cronjob (using same tool as during
>>  boot except with more bits taken from the kernel)
>>• updates (the second 64-byte half, from urandom) it on shutdown

Let’s take the second bullet point first: I’m adding 64 bytes from
whatever the system has in its RNG during shutdown. This is the
step where entropy for the _next_ boot is _normally_ added.

The early-rng-init-tools initramfs part is *not* about gathering
more entropy during boot, it’s to make whatever entropy is there
available earlier. (The regular /var/lib/urandom/random-seed (or
whatever systemd does) thing is *also* *still* done, just later.)

Now, the daily cronjob. It uses the same mechanism as in early
boot, but without the -E parameter, so it reads a few bytes more
from the kernel. On Linux, the exact numbers (modulo things like
dmesg and time which are only used to diversify) are:

• with -E (early boot):
  ‣ with AT_RANDOM
– 16 bytes from AT_RANDOM (possibly shared with
  other code in the same executable)
  ‣ without AT_RANDOM
– 4 bytes from /dev/urandom
  (although all of them are probably not very random)

• without -E (daily cronjob):
  ‣ with AT_RANDOM
– 16 bytes from AT_RANDOM (possibly shared with
  other code in the same executable)
– 8 bytes from /dev/urandom
  ‣ without AT_RANDOM
– 16 bytes from /dev/urandom
  (and all of these are during normal system runtime,
  so should be random enough, otherwise you have a
  problem ANYWAY)

So, in the cronjob case, we get 128 to 192 bits from the
kernel. Tytso said that using 128 bits to initialise a
good RNG is probably enough for a lot… and we *do* also
add the 128 *bytes* (1024 bit) from the seedfile.

If the postinst (first time 1024 bits get written into
the seed file), cronjob (where the seed file is mixed
with another 128/192 bit from the kernel), shutdown
(where 512 bits in the seedfile are overwritten with
512 fresh bits from /dev/urandom) do not have entropy
enough, you have a different problem. Use something like
ekeyd with Simtec’s EntropyKey (which I do), or type more
on the keyboard, or, if you really must, use haveged or
something like that. My early-rng-init-tools does not
address that, you still have to ensure regular entropy
collection during normal system runtime happens and is
good enough. It’s really *just* about getting it usable
earlier in the boot process.

Perhaps you (or someone from l10n-en) could suggest
wording to that effect I could add to the package
description, or perhaps even a README? (Maybe I should
write a README anyway. I need to work on other stuff,
freeze/BSP-relevant but also real life-relevant, for
now, but I’ll revisit this anyway…)

I’ll take all feedback into account by then.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

Re: FYI/RFC: early-rng-init-tools

[Ben Hutchings]

On Mon, 2019-02-25 at 16:48 +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
> 
> >> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
> >>   accredit them yet, just remembers the amount written)
> >
> >How do you determine the number of bytes here?
> 
> 32 + arc4random_uniform(256 - 32 + 1)

OMG.  Don't randomise the length.

[...]
> If the postinst (first time 1024 bits get written into
> the seed file), cronjob (where the seed file is mixed
> with another 128/192 bit from the kernel), shutdown
> (where 512 bits in the seedfile are overwritten with
> 512 fresh bits from /dev/urandom) do not have entropy
> enough, you have a different problem.
[...]

Yes, but your implementation fails open in that case.  In early boot
you should remove the seed file rather than creating it with
insufficient entropy.

To refresh the seed file, you should start a service at boot that does
a blocking read from /dev/random (not /dev/urandom).  Possibly it
should sleep a few minutes or have dependencies that prevent it from
taking away entropy from other services.

I don't see the point of doing this repeatedly in a cron job.  And you
can't do it properly at shutdown since you shouldn't block then.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Re: FYI/RFC: early-rng-init-tools

[Ben Hutchings]

On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
[...]
> Generally you don't ever
> need to use /dev/random instead of /dev/urandom unless you make
> assumptions about cryptography failing.
[...]

I think I agree with that, but there is no way to add entropy that
unblocks getrandom() without also unblocking /dev/random.  If the seed
files used in two different boots are somewhat correlated, and the
entropy estimation doesn't account for that, the output of /dev/random
may also be somewhat correlated between the boots, which is not
supposed to happen.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Re: FYI/RFC: early-rng-init-tools

[Sebastian Andrzej Siewior]

On 2019-02-24 19:52:59 [+], Thorsten Glaser wrote:
> tl;dr: it adds entropy during initramfs/as early as possible during
> boot *and* tells the kernel it did so, to make its crng initialised,
> and ensures a subsequent boot has a different seed, also updated
> periodically and on shutdown for added entropy carry-over.

so I have one older box that suffers from that. I installed haveged and
seemed to went away:

[1.600832] random: fast init done
[2.417621] systemd[1]: systemd 240 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[8.685406] random: crng init done

So what is the advantage over using haveged?
As far as I understand, it would reach the "init done" state before
systemd took over, right?

Sebastian

Re: FYI/RFC: early-rng-init-tools

[Sam Hartman]

> "Ben" == Ben Hutchings  writes:

Ben> The output of the RNG may well become public, for example in
Ben> document UUIDs.  So when estimating the entropy that the new
Ben> seed file will provide for the next boot, none of the entropy
Ben> in the old seed file should be credited.

Are you saying that you believe that given output from the RNG it is
cryptographically feasible to determine the seed?

There's a trivial reduction from that claim to a proof that the PRNG is
not in fact a PRNG.

Unless there are cryptology results I'm unaware of--and it has been a
few years since I studied the construction of PRNGs--then I don't think
your argument is reasonable.
A PRNG should be secure so long as its seed stays secret.

Now, there are a lot of ways that a seed can become not secret.  So I
don't think our default should be to assume that a seed is secret.
However, especially on platforms that don't have good hardware, I do
think having a quick package you can install that gives reasonable
operation under the assumption you keep your PRNG seed secret is very
valuable.
It shouldn't be the default out of the box, but it should be easy to
turn on because it's a common configuration for our users.

What am I missing here?


signature.asc
Description: PGP signature

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Julian Andres Klode]

On Tue, Feb 19, 2019 at 05:49:24AM +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2018-11-20 at 22:16:17 +0100, Adam Borowski wrote:
> > Thus, it seems to me that the plan A for usrmerge has serious downsides for
> > dubious benefits.  What about the plan B I described above?
> 
> So, people still seem to be conflating merged-/usr (the filesystem
> layout) with the different ways to deploy it. Personally I do agree
> that merged-/usr has benefits, and that's why I've f.ex. been switching
> the shared library packages I maintain to do a proper and correct switch
> by installing their files in /usr/lib instead of /lib.
> 
> The underlaying problem with the merged-/usr-via-symlinks is not
> really that it has generated bugs, many transitions we perform incur
> those, for the better. The problem is that it has generated those when
> it was really not necessary in the first place, has made things
> unnecessarily more complicated for everyone, and it's a terrible hack
> trying to reap "quick" benefits at the cost of everyhing else, with
> long lasting consequences even after a full migration to /usr would
> have been finished. And here's why:
> 
> 1) The merged-/usr-via-symlinks deployment method used by both
>debootstrap and usrmerge, means that those systems will get
>permanent filesystem aliasing problems, forever. Even when all
>files might have been moved to their /usr counterparts in the
>packages! This is due to the fact that different pathnames can
>end up pointing (before any canonicalization!) to the same dentry.

This is IMO the most important feature of usrmerge: It does not matter
whether you use /usr/$bar or /$bar, you'll get the same result. Hence
/bin is a symlink to /usr/bin and so on, so you get the same binaries
and libraries in both places.

Having symlinks in /bin and so on would be unclean: We'd have to maintain
one symlink per binary in /usr. This is a lot of symlinks. We also cannot
ever get rid of them - it would break the property.

It also fails to handle subdirectories in lib{exec}. We do want
/usr/lib/systemd and /lib/systemd to be the same.

I don't think there is any other way that sensible handles merging
subdirectories, and therefore, the only reasonable way is to continue
with the current way, and patch up software to normalize /{bin,sbin,lib}
to /usr/bin when they see it on an usrmerged system.

I admit that this is painful, but I think it is worth it.

> 2) It bypasses the packaging system understanding of what is on the
>   filesystem and creates mismatches between what's on binary packages
>   and what's on disk.

I agree that this is a problem. But it seems to me it is a solvable
one.

> 4) Due to having to support the broken merged-/usr-via-symlinks
>deployment, when we want to move the contents of the binary
>packages to the merged-/usr layout, we require now to include tons
>of logic in (probably new) maintainer scripts, when we have been
>trying to remove them altogether. :( With even more files untracked
>by dpkg itself, bypassing the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.

The solution here seems simple: If you do not want a usrmerged
system, but do want to move binaries to /usr, build a symlink farm
manager into dpkg that automatically creates symlinks in /$foo for
files in /usr/$foo (for some values of $foo), rather than having
packages ship compat themselves.

That would get you support for merged binaries and libraries, but
not for merged lib directories. It's unclear to me how you'd handle
those, hence I mentioned that /lib -> /usr/lib is the only sensible
answer.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Russ Allbery]

Julian Andres Klode  writes:

> Having symlinks in /bin and so on would be unclean: We'd have to maintain
> one symlink per binary in /usr. This is a lot of symlinks.

Does the quantity of symlinks matter?

> We also cannot ever get rid of them - it would break the property.

Well, on any given system, once every file in /bin was a symlink to the
same-named file in /usr/bin and we had some guarantee that no new packages
would break this property, we could in theory replace the entire directory
with a symlink.  Doing that feels like it would require new primitives in
the package management software, though, and it might be hard to do
safely.  (It would also create a break point where packages from before
that flag day could no longer be installed on the system.)

> It also fails to handle subdirectories in lib{exec}. We do want
> /usr/lib/systemd and /lib/systemd to be the same.

You can use the same approach recursively and symlink every file.  This is
an old package manager trick that I think Nix is still using to this day,
and which was used to some success by such things as GNU stow (albeit for
different reasons).

-- 
Russ Allbery (r...@debian.org)   

Report from Debian BSP at tarent solutions GmbH, Bonn

[Dominik George]

Hi everybody,

here is a short report from the bug squashing party, which took place at
tarent solutions GmbH[1], Bonn, Germany, the last weekend. It was
poartially sponsored by tarent solutions and partially by Teckids[2], with
tarent sponsoring rooms and drinks, and Teckids sponsoring network and
food.

We had a very nice weekend with ten different people attending,
including two new contributors from Italy (one of them from Tarent in
southern Italy - nice coincidence, if you followed closely ;)). I am
very proud that we managed to have a, form my point of view, very good
balance between -project and -devel work, and also socialising. The two
perosns from Italy got to know some of our tools, and fixed their first
two bugs, and concluded that they would invest some more time into
Debian in the future. I also spent several hours in the kitchen,
creating more or less creative food (called "live catering" by one
attendee) troughout the days ;). I very much enjoyed this .

Now, coming to the technical stuff:

It looks like we touched 38 RC bugsthis weekend, which is close to an
impressing 10% of all RC bugs in buster atthis time. To be fair, we
merged a lot. The bugs that remained at the end are listed at [3]. Here
are short summaries:

 * Paolo and Thorsten made a lot of packagres build their documentation
   again, after a bug in a TeX package broke doxygen.
 * Christoph fixed a legal issue in a row of netkit-* related packages,
   which contained stuff without accompanying source. If he really uploads,
   we are sadly losing an important BSP running gag ;)!
 * Antonio and me fixed an issue installing freeipmi tools due to incomplete
   default settings for service startup.
 * I fixed several bugs in sssd which made it fail to build.
 * A row of test failures due to minor changes in dependencies were fixed.
 * Python packages installign header files to wrong locations were fixed
   in a row.
 * A SEGFAULT in midori when editing proxy settings was fixed, and sent
   and applied upstream.
 * Other stuff I failed to list here.

We also had two people attend looking for inspiration for their own BSP,
and we are now expecting another BSP in Germany at the beginning of May
;).

As the main organiser, I want to thank everyone who attended for making
this weekend so great. tarent, Teckids and me were very proud to be your
hosts, and are looking forward to welcoming you on board again ☺!

Cheers,
Nik

[1] http://www.tarent.de
[2] https://www.teckids.org
[3] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-rele...@lists.debian.org;tag=bsp-2019-02-de-bonn


signature.asc
Description: PGP signature

Re: Bug#923221: ITP: libpam-fingerprint -- Pluggable Authentication Module for fingerprint authentication

[Paul Wise]

On Mon, Feb 25, 2019 at 7:14 PM Philipp Meisberger wrote:

> Poorly libpam-fprintd is not suitable as libfprint0 seems to support
> ZhianTec fingerprint sensors. libpam-fingerprint is especially for those
> sensors. I see it would be more precise to use "Pluggable Authentication
> Module for ZhianTec fingerprint sensors" as description and name the
> package "libpam-fingerprint-zfm".

Is it feasible to merge the two projects upstream? It seems like
having two different fingerprint sensor stacks and have the user
manually decide which one they want and then install it is a bit of a
suboptimal experience. It would be nicer if there were one stack that
supported all the fingerprint sensors available on the market.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Salsa CI news

[Paul Wise]

On Mon, Feb 25, 2019 at 11:22 PM Roberto C. Sánchez wrote:
>
> On Mon, Feb 25, 2019 at 02:44:22PM +, Jonathan Dowland wrote:
> > On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:
> > > On behalf of the Salsa CI Team I'm pleased to announce some of the
> > > changes we've been working on this weekend. We don't have an official
> > > mailing list, so please excuse us if this is not the place for this
> > > kind of announcements.
> >
> > Thanks for sharing! Personally I think you could consider using
> > debian-devel-annou...@lists.debian.org (but others may disagree)
> >
> At the very least make sure the publicity team knows so it makes it into
> the next Debian Project News issue.

Misc Dev News seems more appropriate here:

https://wiki.debian.org/DeveloperNews

-- 
bye,
pabs

https://wiki.debian.org/PaulWise