Re: Handling of entropy during boot
On Tue, 8 Jan 2019, Theodore Y. Ts'o wrote: > On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote: > > > > If the security issue only affects a small percentage of the installations > > and fixing it means breaking many other installations, then there has to > > be a discussion if we really want fix the issue or if a "don't do that" > > documentation is the better choice. > > One of the questions which needs to be answered is exactly how many > installations are actually broken. I don't think it's going to be bad > as you suspect There have been a number of bug reports and blog posts about this, despite buster not being release yet. So it's not that uncommon. > > > Rasberry PIs were only an example. There are also other systems, including > > old x86 systems, that don't have a HWRNG. Also, there are probably a load > > of x86 VMs that emulate an older CPU due to libvirt misconfiguration and > > don't expose the rdrand cpuid bit. > > x86 systems have a high resolution timer; Rasberry PI's don't. > Furthermore, if libvirt is miconfigured, it should just be fixed (and > better yet, it should be configured to enable virtio-rng, which is > *not* hard). It can be very hard if the VM host is not under your control. > > Systems that don't suffer from blocking on entropy because they have other > > sources of entropy (hwrng, ...) won't have their security reduced because > > the good entropy will still be added to the pool, regardless of the seed > > file being credited or not. > > The question is how long they have to block. *Very* unfortunately, > there's a lot of busted software that try to generate > security-critical keys when the system is first booted, which is when > entropy available is the least available. Such packages include ssh > and various packages which call openssl (such as CUPS) which are > visible to the internet. > > And if the system doesn't have good sources of entropy, and don't have > sufficient interrupts to initialize the entropy pool, the question is > what should we do? Should we just blindly proceed and let them > generate insecure keys? At least, if the system blocks, they'll know > something is wrong, and they can fix the problem (for example, such as > *fixing* their libvirt configuration). At the very least, there must be a clear message what the problem is. People having to use strace to figure out what is broken is just not acceptable. > Ultimately, I don't think it's a big problem, primarily because I'm > not hearing a lot of yelling from Debian users. I think the amount of yelling is already quite high, considering that it's only for testing and the vast majority of large deployments only use stable. I have included some links in my first mail. > It may be annoying > for your Rasberry Pi system, but the question is whether that is a > common case or an isolated case. > > So, how could we go forward from here. Maybe we could limit the wait for > > entropy to some reasonable value (1 minute? 5 minutes?). This could be > > done by creating a program that does a blocking getrandom but with a > > timeout. If the timeout expires and the seed file has been read > > successfully before, it would then credit the read entropy. This program > > would be added as systemd unit so that services that need entropy can > > depend on it and don't get killed with a timeout. Is this a reasonable > > approach? Or do you (or anyone else) have any better suggestions? > > My suggest is to try and figure out *what* is blocking, and *why*. If > it's because it's something security-critical, such as generating ssh > keys, letting things continue even though we don't have secure entropy > is a bad, bad, BAD idea. If it's for something stupid, like > generating seeds for Python dictionaries (just as an example; that one > has been fixed) then the application should be fixed not to request > secure randomness in the first place. No, that's utterly wrong. If it's a hassle to use good entropy, people will use gettimeofday() for getting "entropy" and they will use it for security relevant purposes. In this way, you would achieve exactly the opposite of what you want. Any program that does secure network connections needs entropy for Diffie-Hellman. And even seeds for hash buckets can be security relevant. You really don't want that people need to distinguish between security-critical and stupid uses of entropy, because they WILL get it wrong. For the most part, daemons block during startup because openssl decides it wants entropy for something. This is really difficult to change without creating other security issues. > That's the correct fix, as opposed to a short cut that might leave us > in worst place, from a security perspective. We already were there with the random() library call, and that was not a good situation. People used it for everything, including security-critical stuff. Now people have been educated to use good entrop
Bug#918796: ITP: yorick-full -- full installation of the Yorick interpreter and add-ons
Package: wnpp Severity: wishlist Owner: Thibaut Paumard * Package name: yorick-full Version : 2.2.04+dfsg1+full Upstream Author : Thibaut Paumard * URL : http://yorick.sourceforge.net * License : GPL-2+ Programming Lang: None (metapackage) Description : full installation of the Yorick interpreter and add-ons This binary package is currently built by the yorick source package with the severe drawback that any RC bug in any yorick add-on immediately makes the full Yorick system RC buggy. I'm splitting this metapackage out of the yorick source package to alleviate that. This is the long description: Yorick is an interpreted programming language for: * scientific simulations or calculations * postprocessing or steering large simulation codes * interactive scientific graphics * reading, writing, and translating large files of numbers . The yorick-full metapackage installs Yorick together with the full set of add-ons packaged for Debian. . You may prefer to only install the yorick package and cherry-pick the yorick-* add-ons you need. . If you need MPY, the MPI parallel version of Yorick, please install either yorick-mpy-openmpi or yorick-mpy-mpich2 in addition.
Bug#918805: ITP: suricata-update -- tool for updating Suricata rules
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: suricata-update Version : 1.0.3 Upstream Author : OISF * URL : https://github.com/OISF/suricata-update * License : GPLv2 Programming Lang: Python Description : tool for updating Suricata rules suricata-update is a tool to easily and reliably fetch and update rule sets for the Suricata IDS/IPS system. It queries external upstream rule sources such as Emerging Threat/Proofpoint's rule sets and others, taking into account user accounts and preferences, and merges all rules into one file to be loaded into Suricata. This is a newly developed software tool and the one currently recommended by Suricata's upstream for rule maintenance.
quilt + dpkg + debhelper: Handling upstream files containing spaces
Hi all, I am a little clueless about the below. I hope that someone can shed some light or provide a work-around. I am currently working on OpenBoard packaging. OpenBoard ships loads of embedded jquery.* copies of code (and other JS libs, too). Those jquery.* et al. files are in folder paths that contain blanks. Ouch. It seems that our tool chain components fail completely on handling them. Or maybe I am doing entirely wrong. ** Approach 1 **: While repacking, remove all those jquery.* et al. files and replace them in the installed package via symlinks to /usr/share/javascript/jquery*. So, I placed a debhelper file (debian/openboard-common.links) into the package folder and populated it with symlink dests and targets. Of course, I frowned at myself and * quoted those dirs containing strings with double quotes * ... with single quotes * ... tried with dh-exec and quotes * ... tried it with backslash + blank escpaing ... but to no avail... I worked around this issue with [1]: Rename the folders that contain blanks and the dh_link works ok. Unfortunately, those folder names get displayed ot the user in the OpenBoard UI. Yes, that's faulty by design, but that's not with this mail is supposed to be about. So... Ok, let's forget about that symlink hell anyway. It makes the installed package unnecessarily unclean. So... ** Approach 2 **: While repacking, again remove all those jquery.* et al. files but not replace them later on by symlinks. Instead patch various *.html files in the source code tree at build time and put absolute files names of the JS library as provided by Debian packages into those files' html header. This works fine for to-be-patched files that are not in a folder path containing blanks. For folder paths containing blanks, I get this: * it is already hard to add those blank-containg file paths to quilt (quilt add "...\ ..." IIRC, quotes plus escaping, I may remember this inaccurately at the time of writing this) * once the to-be-patched files got added, I started editing / modifying those files * quilt refresh * quilt pop -a -> OK * quilt push -a -> failure * ... quilt (or patch rather) fails to apply the patch, because it interprets the filenames in the '--- a/...' and '+++ b/...' lines only until the first blank (so half way down the file path) * investigating the patch reveals, that the blanks are not escaped, neither are they quoted or anything * so, I add double quotes around all file paths * now I can quilt push and pop again (if you quilt refresh, then the quotes gone again...) * then I run debuild -uc -us -S and dpkg fails to apply the patch with this message: dpkg-source: error: diff openboard/debian/patches/2008_use-Debian-js-libraries.patch patches file with C-style encoded filename * same situation with single quotes Anyone any idea??? Thanks in advance, Mike [1] https://salsa.debian.org/debian-edu-pkg-team/openboard/commit/8ce4fc101ad80caa068222f0b8839e19e6ef52ac -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpAVf89W7Rb7.pgp Description: Digitale PGP-Signatur
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
Mike Gabriel writes ("quilt + dpkg + debhelper: Handling upstream files
containing spaces"):
> I am currently working on OpenBoard packaging. OpenBoard ships loads
> of embedded jquery.* copies of code (and other JS libs, too).
>
> Those jquery.* et al. files are in folder paths that contain blanks.
> Ouch. It seems that our tool chain components fail completely on
> handling them. Or maybe I am doing entirely wrong.
Grlgk.
> I worked around this issue with [1]: Rename the folders that contain
> blanks and the dh_link works ok. Unfortunately, those folder names get
> displayed ot the user in the OpenBoard UI. Yes, that's faulty by
> design, but that's not with this mail is supposed to be about.
Nglgkkrgl.
I don't have any other perfect suggestions, but I do have a suggestion
is IMO tolerable and which you may find less bad than other approaches:
* Use the 1.0 native source package format. Ie, no orig tarballs,
use one tarball, like you would for a Debian-native package.
(You may need to override an overzealous lintian warning.)
* Use one of `git merge' or `git debrebase' to manage your
delta from upstream. (Disclosure: I wrote `git-debrebase'.)
These tools can work with your delta entirely in git and
will not be troubled by the spaces in the filenames.
Then you do not need to represent the changes you make as patch files
suitable for diff.
With git-debrebase you can even continue to separate your changes out
into a `patch queue': a rebasing linear series of commits
(git-debrebase calls it a `delta queue' because they're not patches
then).
With either of these approaches you can no longer publish the delta
queue as a series of patches - but you can't really do that anyway,
since even with your other approaches part of your delta is a
repacking phase.
The other downside of this approach is that you need to re-upload the
whole upstream source code with every Debian upload. I'm not sure how
big your upstream source is. If it is big, then this is not a good
approach.
I do have an idea how to fix this: a source package format
`3.0 (rsync)', which could represent any delta. But that project
is stalled at a conceptual stage, mostly due to the need to support
existing ftpmaster workflow :-/.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
On Wednesday, 9 January 2019 15:22:32 CET Mike Gabriel wrote: > Those jquery.* et al. files are in folder paths that contain blanks. > Ouch. It seems that our tool chain components fail completely on > handling them. Or maybe I am doing entirely wrong. This looks like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198507 :-/
Re: Handling of entropy during boot
On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote: > > There have been a number of bug reports and blog posts about this, despite > buster not being release yet. So it's not that uncommon. Pointers, please? Let's see them and investigate. The primary issue I've been aware of to date has been on Fedora systems, and it's due to some Red Hat specific changes that they made for FEDRAMP compliance --- and Red Hat has dealt with those issues. If there are problems for people using Debian Testing, we should investigate them and understand what is going on. > > My suggest is to try and figure out *what* is blocking, and *why*. If > > it's because it's something security-critical, such as generating ssh > > keys, letting things continue even though we don't have secure entropy > > is a bad, bad, BAD idea. If it's for something stupid, like > > generating seeds for Python dictionaries (just as an example; that one > > has been fixed) then the application should be fixed not to request > > secure randomness in the first place. > > No, that's utterly wrong. If it's a hassle to use good entropy, people > will use gettimeofday() for getting "entropy" and they will use it for > security relevant purposes. In this way, you would achieve exactly the > opposite of what you want. If *users* do this, then if they end up releasing credit card numbers or PII or violate their customers privacy which brings the EU's GDPR enforcers down on then, it's on *their* heads. If *Debian* makes a local Debian-specific change which causes these really bad outcomes, then it's on *ours*. We've tried to do this ten years ago, when well-meaning Debian Developers tried to "fix" OpenSSL's random number library, and it turned out to be a disaster[1]. So let's be careful and to replicate past mistakes, eh? [1] https://www.schneier.com/blog/archives/2008/05/random_number_b.html > Any program that does secure network connections needs entropy for > Diffie-Hellman. And even seeds for hash buckets can be security relevant. > You really don't want that people need to distinguish between > security-critical and stupid uses of entropy, because they WILL get it > wrong. Sure, this is why developers need to investigate the bugs. You said you provided links, but I couldn't find any in your e-mail messages or earlier ones on this thread. Perhaps I missed them; in which case, my apologies. Can you please send/resend those links? Can you please prioritize reports from people running Debian Unstable or Debain Testing? As I said above, these issues tend to be very distro specific, especially when distros are messing around with crypto-related libraries in order to keep the US Government happy. - Ted
Re: Handling of entropy during boot
On Wed, Jan 9, 2019 at 12:13 PM Theodore Y. Ts'o wrote: > On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote: > > > > There have been a number of bug reports and blog posts about this, > despite > > buster not being release yet. So it's not that uncommon. > > Pointers, please? Let's see them and investigate. https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616 There's lots of chatter in the systemd github isses, too. I've been bitten by both ssh taking forever and puppet timing out on VMs. I'll need to investigate about virtio-rng. I've got an embedded x86-64 system where lightdm starts quickly when I am plugged into an ethernet connection, but takes about 8 minutes when the ethernet is disconnected. I am very suspicious of the low entropy in this case, too. -m
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
HI Dominique, On Mi 09 Jan 2019 16:29:06 CET, Dominique Dumont wrote: On Wednesday, 9 January 2019 15:22:32 CET Mike Gabriel wrote: Those jquery.* et al. files are in folder paths that contain blanks. Ouch. It seems that our tool chain components fail completely on handling them. Or maybe I am doing entirely wrong. This looks like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198507 :-/ Gotcha. The dh_link(s) failure is exactly what people discuss in #198507. Gosh, that's an ancient one. Unfortunately, the ?-wild-card workaround won't work with symlinking. @Niels Thykier: any status update on #198507? Wonder, if the quilt / dpkg-source issue already has a representation in BTS, too. Thanks for everyone's feedback so far. More ideas? Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpwQb_cB2wh2.pgp Description: Digitale PGP-Signatur
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
Hi Ian,,
On Mi 09 Jan 2019 16:13:57 CET, Ian Jackson wrote:
Mike Gabriel writes ("quilt + dpkg + debhelper: Handling upstream
files containing spaces"):
I am currently working on OpenBoard packaging. OpenBoard ships loads
of embedded jquery.* copies of code (and other JS libs, too).
Those jquery.* et al. files are in folder paths that contain blanks.
Ouch. It seems that our tool chain components fail completely on
handling them. Or maybe I am doing entirely wrong.
Grlgk.
:-)
I worked around this issue with [1]: Rename the folders that contain
blanks and the dh_link works ok. Unfortunately, those folder names get
displayed ot the user in the OpenBoard UI. Yes, that's faulty by
design, but that's not with this mail is supposed to be about.
Nglgkkrgl.
:-D (grin...)
I don't have any other perfect suggestions, but I do have a suggestion
is IMO tolerable and which you may find less bad than other approaches:
* Use the 1.0 native source package format. Ie, no orig tarballs,
use one tarball, like you would for a Debian-native package.
(You may need to override an overzealous lintian warning.)
* Use one of `git merge' or `git debrebase' to manage your
delta from upstream. (Disclosure: I wrote `git-debrebase'.)
These tools can work with your delta entirely in git and
will not be troubled by the spaces in the filenames.
Then you do not need to represent the changes you make as patch files
suitable for diff.
With git-debrebase you can even continue to separate your changes out
into a `patch queue': a rebasing linear series of commits
(git-debrebase calls it a `delta queue' because they're not patches
then).
With either of these approaches you can no longer publish the delta
queue as a series of patches - but you can't really do that anyway,
since even with your other approaches part of your delta is a
repacking phase.
The other downside of this approach is that you need to re-upload the
whole upstream source code with every Debian upload. I'm not sure how
big your upstream source is. If it is big, then this is not a good
approach.
The source package is 20M+ big. Not really big, but not really small, either
I do have an idea how to fix this: a source package format
`3.0 (rsync)', which could represent any delta. But that project
is stalled at a conceptual stage, mostly due to the need to support
existing ftpmaster workflow :-/.
So this is mere theory, so far. Right?
Regards,
Ian.
Thanks for the feedback.
I will do more breeding on it...
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
pgpuTwq1qUppB.pgp
Description: Digitale PGP-Signatur
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
Mike Gabriel: > Hi all, > > I am a little clueless about the below. I hope that someone can shed > some light or provide a work-around. > > I am currently working on OpenBoard packaging. OpenBoard ships loads of > embedded jquery.* copies of code (and other JS libs, too). > > Those jquery.* et al. files are in folder paths that contain blanks. > Ouch. It seems that our tool chain components fail completely on > handling them. Or maybe I am doing entirely wrong. > Yupe, that is https://bugs.debian.org/198507 (as Dominique mentioned). I am happy to work with someone on fixing this while ensuring dh-exec keeps working. FTR: dh-exec is orphaned and I have no plans to pick it up as I want a higher bus factor than 1 in our low level packaging stack. > ** Approach 1 **: > > While repacking, remove all those jquery.* et al. files and replace them > in the installed package via symlinks to /usr/share/javascript/jquery*. > > So, I placed a debhelper file (debian/openboard-common.links) into the > package folder and populated it with symlink dests and targets. Of > course, I frowned at myself and > > * quoted those dirs containing strings with double quotes > * ... with single quotes > * ... tried with dh-exec and quotes > * ... tried it with backslash + blank escpaing > > ... but to no avail... > For most other cases, you can "work around" the issue by (ab)using globs (e.g. ? or *) as there are rarely another path with the same name modulo space replaced by another glyph. But even that fails here as dh_link do not use globs AFAIR. However, for dh_link you *can* pass the file names as arguments and it will work: dh_link -pfoo "path with space" "another path with even more spaces" Which still leaves much to be wanted, but it works. (Sadly, this is made worse by dh_install and others "splitting" properly quoted paths because people have started to rely on the argument being split. The result is that is helpers are inconsistent about how they handle spaces in arguments and the result is much sadness /o\) Anyway, hope it helps. Thanks, ~Niels
Re: Handling of entropy during boot
On Wed, 2019-01-09 at 11:40 -0500, Theodore Y. Ts'o wrote: > On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote: [...] > > No, that's utterly wrong. If it's a hassle to use good entropy, people > > will use gettimeofday() for getting "entropy" and they will use it for > > security relevant purposes. In this way, you would achieve exactly the > > opposite of what you want. > > If *users* do this, then if they end up releasing credit card numbers > or PII or violate their customers privacy which brings the EU's GDPR > enforcers down on then, it's on *their* heads. If *Debian* makes a > local Debian-specific change which causes these really bad outcomes, > then it's on *ours*. > > We've tried to do this ten years ago, when well-meaning Debian > Developers tried to "fix" OpenSSL's random number library, and it > turned out to be a disaster[1]. So let's be careful and to replicate > past mistakes, eh? It's a bit late for that: https://lists.debian.org/debian-release/2018/05/msg00130.html [...] > Sure, this is why developers need to investigate the bugs. You said > you provided links, but I couldn't find any in your e-mail messages or > earlier ones on this thread. Perhaps I missed them; in which case, my > apologies. Can you please send/resend those links? [...] I sent you a bunch of bug links in message in August. Ben. -- Ben Hutchings Every program is either trivial or else contains at least one bug signature.asc Description: This is a digitally signed message part
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
Hi Niels, On Mi 09 Jan 2019 21:24:00 CET, Niels Thykier wrote: Mike Gabriel: Hi all, I am a little clueless about the below. I hope that someone can shed some light or provide a work-around. I am currently working on OpenBoard packaging. OpenBoard ships loads of embedded jquery.* copies of code (and other JS libs, too). Those jquery.* et al. files are in folder paths that contain blanks. Ouch. It seems that our tool chain components fail completely on handling them. Or maybe I am doing entirely wrong. Yupe, that is https://bugs.debian.org/198507 (as Dominique mentioned). I am happy to work with someone on fixing this while ensuring dh-exec keeps working. FTR: dh-exec is orphaned and I have no plans to pick it up as I want a higher bus factor than 1 in our low level packaging stack. I can test with both tools (dh_link and dh-exec). (I won't adopt dh-exec, though. My Perl is not good enough). ** Approach 1 **: While repacking, remove all those jquery.* et al. files and replace them in the installed package via symlinks to /usr/share/javascript/jquery*. So, I placed a debhelper file (debian/openboard-common.links) into the package folder and populated it with symlink dests and targets. Of course, I frowned at myself and * quoted those dirs containing strings with double quotes * ... with single quotes * ... tried with dh-exec and quotes * ... tried it with backslash + blank escpaing ... but to no avail... For most other cases, you can "work around" the issue by (ab)using globs (e.g. ? or *) as there are rarely another path with the same name modulo space replaced by another glyph. But even that fails here as dh_link do not use globs AFAIR. However, for dh_link you *can* pass the file names as arguments and it will work: dh_link -pfoo "path with space" "another path with even more spaces" To many links to put line-by-line into debian/rules. (I could us ln -s in debian/rules, too). Either way, debian/rules will become hardly readable with the masses of symlinks required. Which still leaves much to be wanted, but it works. Ack. (Sadly, this is made worse by dh_install and others "splitting" properly quoted paths because people have started to rely on the argument being split. The result is that is helpers are inconsistent about how they handle spaces in arguments and the result is much sadness /o\) Anyway, hope it helps. Thanks for the explanations. Thanks, ~Niels Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpr7e1SpbjyP.pgp Description: Digitale PGP-Signatur
Re: quilt + dpkg + debhelper: Handling upstream files containing spaces
Mike Gabriel writes ("Re: quilt + dpkg + debhelper: Handling upstream files
containing spaces"):
> On Mi 09 Jan 2019 16:13:57 CET, Ian Jackson wrote:
> > I do have an idea how to fix this: a source package format
> > `3.0 (rsync)', which could represent any delta. But that project
> > is stalled at a conceptual stage, mostly due to the need to support
> > existing ftpmaster workflow :-/.
>
> So this is mere theory, so far. Right?
Unfortunately so. And deploying it would be a big deal with a
1-release-cycle lag.
Sorry,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 sorry using phone to type, mike, comment 25 shows some important options to ld gold would it be possible to retry with those? 32 bit. Disabling mmap looks really important as clearly a 4gb+ binary is guaranteed going to fail to fit into 32bit mmap. On Tuesday, January 8, 2019, Mike Hommey wrote: > > Note that Firefox is built with --no-keep-memory > --reduce-memory-overheads, and that was still not enough for 32-bits > builds. GNU gold instead of BFD ld was also given a shot. That didn't > work either. Presently, to make things link at all on 32-bits platforms, > debug info is entirely disabled. I still need to figure out what minimal > debug info can be enabled without incurring too much memory usage > during linking. > > Mike > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Bug#918862: ITP: ruby-momentjs-rails -- wraps the Moment.js library in a rails engine for asset pipeline
Package: wnpp Severity: wishlist Owner: =?utf-8?b?QW5kcmV3IExlZSAo5p2O5YGl56eLKQ==?= * Package name: ruby-momentjs-rails Version : 2.20.1 Upstream Author : Derek Prior * URL : https://github.com/derekprior/momentjs-rails * License : MIT Programming Lang: Ruby Description : wraps the Moment.js library in a rails engine for asset pipeline momentjs-rails wraps the Moment.js library in a rails engine for simple use with the asset pipeline provided by Rails 3.1 and higher. The gem includes the development (non-minified) source for ease of exploration. The asset pipeline will minify in production. . Moment.js is "a lightweight javascript date library for parsing, manipulating, and formatting dates." Moment.js does not modify the native Date object. Rather, it creates a wrapper for it.
Re: Handling of entropy during boot
On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote: > > If the security issue only affects a small percentage of the installations > and fixing it means breaking many other installations, then there has to > be a discussion if we really want fix the issue or if a "don't do that" > documentation is the better choice. One of the questions which needs to be answered is exactly how many installations are actually broken. I don't think it's going to be bad as you suspect > Rasberry PIs were only an example. There are also other systems, including > old x86 systems, that don't have a HWRNG. Also, there are probably a load > of x86 VMs that emulate an older CPU due to libvirt misconfiguration and > don't expose the rdrand cpuid bit. x86 systems have a high resolution timer; Rasberry PI's don't. Furthermore, if libvirt is miconfigured, it should just be fixed (and better yet, it should be configured to enable virtio-rng, which is *not* hard). > Systems that don't suffer from blocking on entropy because they have other > sources of entropy (hwrng, ...) won't have their security reduced because > the good entropy will still be added to the pool, regardless of the seed > file being credited or not. The question is how long they have to block. *Very* unfortunately, there's a lot of busted software that try to generate security-critical keys when the system is first booted, which is when entropy available is the least available. Such packages include ssh and various packages which call openssl (such as CUPS) which are visible to the internet. And if the system doesn't have good sources of entropy, and don't have sufficient interrupts to initialize the entropy pool, the question is what should we do? Should we just blindly proceed and let them generate insecure keys? At least, if the system blocks, they'll know something is wrong, and they can fix the problem (for example, such as *fixing* their libvirt configuration). Ultimately, I don't think it's a big problem, primarily because I'm not hearing a lot of yelling from Debian users. It may be annoying for your Rasberry Pi system, but the question is whether that is a common case or an isolated case. > So, how could we go forward from here. Maybe we could limit the wait for > entropy to some reasonable value (1 minute? 5 minutes?). This could be > done by creating a program that does a blocking getrandom but with a > timeout. If the timeout expires and the seed file has been read > successfully before, it would then credit the read entropy. This program > would be added as systemd unit so that services that need entropy can > depend on it and don't get killed with a timeout. Is this a reasonable > approach? Or do you (or anyone else) have any better suggestions? My suggest is to try and figure out *what* is blocking, and *why*. If it's because it's something security-critical, such as generating ssh keys, letting things continue even though we don't have secure entropy is a bad, bad, BAD idea. If it's for something stupid, like generating seeds for Python dictionaries (just as an example; that one has been fixed) then the application should be fixed not to request secure randomness in the first place. That's the correct fix, as opposed to a short cut that might leave us in worst place, from a security perspective. - Ted
