Re: Handling of entropy during boot
On Jan 09, "Theodore Y. Ts'o" wrote: > 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). Can you clarify what is the best practice here? I am finding a lot of conflicting and often obviously clueless advice online. Is it enough to feed the host side of virtio-rng with /dev/random or should everybody who has virtual machines also install rngd in the host? Is rngd to be preferred to haveged? Data points: none of my current virtualization hosts (very new HPE Gen10 and Cisco UCS M5 blades) have an hardware RNG available to the kernel, at least with RHEL 7. When rngd is installed it reports RDRAND and jitter entropy (the rngd internal source, not the kernel module) to be available. -- ciao, Marco signature.asc Description: PGP signature
Bug#919178: ITP: node-webpack-merge -- merge designed for Webpack
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: node-webpack-merge Version : 2.2.0 Upstream Author : Juho Vepsalainen * URL : https://github.com/survivejs/webpack-merge * License : Programming Lang: JavaScript Description : merge designed for Webpack webpack-merge provides a merge function that concatenates arrays and merges objects creating a new object. If functions are encountered, it will execute them, run the results through the algorithm, and then wrap the returned values within a function again. . This behavior is particularly useful in configuring webpack although it has uses beyond it. Whenever you need to merge configuration objects, webpack-merge can come in handy. . There's also a webpack specific merge variant known as merge.smart that's able to take webpack specifics into account (i.e., it can flatten loader definitions). This package is needed to generate browser library for node-jsonld. It will be maintained in the Debian JavaScript team. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlw7PAsACgkQLHwxRsGg ASExmhAAjoXuXh19BFwxQYfJ00rw872gtu83hjQ9dfBPonV6Q/rrPsjm1QPDR20X Kq8zf+e1riaaCoQGH+4wRsm7Mu3E7OVRfBQR+QaCJMNp7drUys6BxeHZhFrgoLIJ hRPUc39590ZMHCmjqHZbsNdiEWrg13NwTf1Lt66/0qBD3ZaCMHMpJN8zPcP1550r GXQUwQoKjpa7/5zcf5ZWgLkhA/K0mfCsHYQw9M+lHBWZ23kifHoJOCbb73tYTd/T fJTIJ9Pgql0aggjkLFvJfCtU6kCODiRAZX7P/dsCrk/24Nzaba28HGAHyNLLXcN8 BhLKFbFWCUrQ/akRe9ph7WX3kr9Tu39v5pUSF3Q8ej36JEOybhgeL8tA8Jm9unQC LQl6VamsmxicLTiggk+JPG+1WWeaf6EJ7ZMZ0tb8p0FhWxSCYulyIcetZBBWtwd7 W93dffXw6DmXA4/sU56MU9VsXA/D+O3LehOT1OzXyk95BvpFPdkh27K4KJBYpKY9 wMJSuVHv8GWs5R6JcAZL3q8peZu5rt72oKLJWGJFNGGlHY+Gm4pMYOA+Y7F7EI7h CujyA+TZ0ezsNXMOv/MB5T/7QqLzjpW264FlyVc5Yd3E013lLVgXAvl3Imi8D2dX 2WGSHdpVxvN6FkbQeZZLUQVmU0sbiVdm7bj1ZqGXKJ6eB4gQQOQ= =+oUA -END PGP SIGNATURE-
[MBF] Moving mountnfs.sh script to runlevel 2
Hello! During resolving issue #551555 of bin:initscripts, I discovered that solution would be move `mountnfs.sh' initscript into runlevels (2 3 4 5). Historically, `mountnfs.sh' was present in runlevel S due the fact, that bin:initscripts were responsible to mounting /usr. Nowdays, /usr is mounted by initramfs, so many scripts could be moved from runlevel S to runlevels (2 3 4 5). Issue is that there is number of initscripts in runlevel S, that depends on $remove_fs, which means /all/ file systems are mounted, not just / and /usr. I ask corresponding maintainers (list at bottom of email) to either * move their scripts to runlevel (2 3 4 5) [preferred] * remove dependency on $remote_fs, if all they need is /usr * replace with dependency on `mountall', if they need one of (/run /dev/shm /tmp) List of affected packages: Alexander Wirt ferm Anibal Monsalve Salazar pidentd Antti Järvinen screen (U) Aurelien Jarno lm-sensors Axel Beckert screen Barak A. Pearlmutter auto6to4 Benda Xu oss4 (U) Chris Hofstaedtler ipsec-tools (U) Christian Ehrhardt dpdk (U) Debian Accessibility Team espeakup Debian ALSA Maintainers alsa-utils Debian DPDK Maintainers dpdk Debian FCoE Team fcoe-utils Debian QA Group eeepc-acpi-scripts zfs-fuse Debian SELinux maintainers policycoreutils Debian X Strike Force xorg Elimar Riesebieter alsa-utils (U) Erich Schubert pyroman gustavo panizzo iptables-persistent (U) ipsec-tools packagers ipsec-tools Jacob Luna Lundberg fcoe-utils (U) Joao Eriberto Mota Filho zvbi Jonathan Wiltshire iptables-persistent Jordi Mallach alsa-utils (U) Jose M Calhariz switchconf Kacper Wysocki prads (U) Laurent Bigonville policycoreutils (U) Liang Guo fcoe-utils (U) Luca Boccassi dpdk (U) Luke Yelavich alsa-utils (U) Matt Grant ipsec-tools (U) Michael Hanke arno-iptables-firewall Michael Meskes quota Noah Meyerhans ipsec-tools (U) Prads package developers prads Roberto C. Sanchez shorewall shorewall-init shorewall-lite shorewall6 shorewall6-lite Romain Beauxis oss4 (U) Russell Coker policycoreutils (U) Samuel Thibault espeakup (U) oss4 oss4 (U) Santiago Ruano Rincón dpdk (U) Stig Sandbeck Mathisen prads (U) Sven Geuer arno-iptables-firewall Sébastien Noel oss4 (U) Thorsten Alteholz setserial tony mancill fcoe-utils (U) Valentin Vidic fcoe-utils (U)
Re: [MBF] Moving mountnfs.sh script to runlevel 2
On Sun, Jan 13, 2019 at 01:31:42PM +, Dmitry Bogatov wrote: > During resolving issue #551555 of bin:initscripts, I discovered that > solution would be move `mountnfs.sh' initscript into runlevels (2 3 4 5). [...] > List of affected packages: I'm not sure so close to the freeze is the right time to fix a 9 year old normal bug if it requires changes to ~42 packages... -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#919190: ITP: wnpp -- KeePassXC-Browser extension for the KeePassXC password manager
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: wnpp Version: 1.3.2 Upstream Author: KeePassXC-Browser team URL: https://github.com/keepassxreboot/keepassxc-browser License: GPL-3, Expat, OFL-1.1, MPL-2.0 Description: Browser extension for KeePassXC with Native Messaging. This browser extension for Firefox and Chromium connects to a running KeePassXC instance and stores/loads credentials for web sites in/from KeePassXC databases. The password manager KeePassXC is already included in Debian and I would prefer to collaboratively maintain the package. On https://salsa.debian.org/fuddl/keepassxc-browser/ I began to initially work on packaging the extension. Some bells and whistles are still missing and I didn't manage to successfully replace included code copies of libjs-jquery and libjs-jquery-ui, yet. For the latter, updated packages in the archive could be sufficient. Cheers - Bruno signature.asc Description: This is a digitally signed message part
Processed (with 1 error): reassign bug
Processing commands for cont...@bugs.debian.org: > reassign 919045 linux-image-4.9.0-8-amd64 Bug #919045 [general] general: System frozen when either soft power-off or unplug USB3.0 harddisk after proper umount Bug reassigned from package 'general' to 'linux-image-4.9.0-8-amd64'. Ignoring request to alter found versions of bug #919045 to the same values previously set Ignoring request to alter fixed versions of bug #919045 to the same values previously set > merge 919045 917206 Bug #919045 [linux-image-4.9.0-8-amd64] general: System frozen when either soft power-off or unplug USB3.0 harddisk after proper umount Unable to merge bugs because: done of #917206 is 'Salvatore Bonaccorso ' not '' package of #917206 is 'src:linux' not 'linux-image-4.9.0-8-amd64' Failed to merge 919045: Did not alter merged bugs. > End of message, stopping processing here. Please contact me if you need assistance. -- 917206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917206 919045: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919045 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: [MBF] Moving mountnfs.sh script to runlevel 2
Dmitry Bogatov writes: > During resolving issue #551555 of bin:initscripts, I discovered that > solution would be move `mountnfs.sh' initscript into runlevels (2 3 4 5). > > Historically, `mountnfs.sh' was present in runlevel S due the fact, that > bin:initscripts were responsible to mounting /usr. Nowdays, /usr is > mounted by initramfs, so many scripts could be moved from runlevel S to > runlevels (2 3 4 5). > > Issue is that there is number of initscripts in runlevel S, that depends > on $remove_fs, which means /all/ file systems are mounted, not just / > and /usr. > > I ask corresponding maintainers (list at bottom of email) to either > * move their scripts to runlevel (2 3 4 5) [preferred] > * remove dependency on $remote_fs, if all they need is /usr > * replace with dependency on `mountall', if they need >one of (/run /dev/shm /tmp) What will happen on systems where users changed the configuration files and these changes are not applied automatically? Ansgar
Greeting, Ckghfwssm Ckghfwssm, getting back concerning request
We are getting back concerning request on a website. HR head saw profile on website and we would like to ask you to be appraisesize up for a career with our business. Earnings: 3,390 behind month, and bonus scheme. Gaze list about basic stipulations is below: - Age 21 +; - Internet access; - Labor authorization in US; Thine Base jobs and obligations: - Assure executive management by prepare across-the-board excerpt record; - Executing cooperation and necessary aid for customers of the company; - Performing the best customer service to ours bedfellow and customers; If you are still interested, email. Waiting for your reply, Becky Seymore
ITP: rumur -- model checker for the Murphi language
Package: wnpp Severity: wishlist Owner: Matthew Fernandez * Package name: rumur Version : 2019.01.12 Upstream Author : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : The Unlicense Programming Lang: C, C++, Python Description : model checker for the Murphi language Rumur is a model checker for use in the formal verification of finite state machines specified in the Murphi modelling language. It is based on a previous tool, CMurphi, and attempts to provide an approximate drop-in replacement for CMurphi. Rumur works by reading an input file describing a collection of state variables and transition rules, from which it generates a C program to verify safety and security properties of this state machine. The generated verifier works by exhaustively exploring the state space, checking for violation of invariants or deadlocks. In comparison to CMurphi, Rumur generates a verifier that runs significantly faster and uses less memory on large input problems. The Murphi modelling language has been used extensively for hardware verification, in particular for analysing cache coherence protocols. Rumur is able to improve existing users’ work flow by decreasing the time to check these models. I am not aware of any other Debian packages that provide this functionality; existing CMurphi users generally build the tool from source. I am the sole developer and maintainer of this tool and intend to be its Debian maintainer as well. I have not packaged or maintained a tool for Debian before, so I am looking for a sponsor.
Bug#919226: ITP: hardening-runtime -- Runtime hardening configuration files
Package: wnpp Severity: wishlist Owner: Yves-Alexis Perez * Package name: hardening-runtime Version : 1 Upstream Author : Yves-Alexis Perez https://salsa.debian.org/corsac/hardening-runtime * License : GPL-2+ Programming Lang: configuration file Description : Runtime hardening configuration files The package contains configuration files (Linux command line and sysctl for now) with settings recommended by the Linux Kernel Self-Protection project (https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings) The package can be used to quickly harden a default Debian installation.
Re: Handling of entropy during boot
> "Marco" == Marco d'Itri writes: Marco> online. Is it enough to feed the host side of virtio-rng Marco> with /dev/random or should everybody who has virtual machines Marco> also install rngd in the host? Is rngd to be preferred to Marco> haveged? I'd also like to point out that virtio-rng is only a solution for kvm. I recently discovered that Vmware appears to have no virtual RNG available to the guest at all. A buster vmware guest will boot but will be unable to start sshd because of lack of entropy for typically five minutes or so. A lot of stuff breaks in that configuration. virtio-rng doesn't help at all. You can claim that Vmware is broken all you want, but a lot of people us it, and we really should produce an operating system that you can ssh into when you boot a bunch of instances in a virtual environment. --Sam
