Re: Bug#919226: ITP: hardening-runtime -- Runtime hardening configuration files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Just a side note on this. The package currently supports sysctl (by dropping a file in /etc/sysctl.d, which should be common enough) and Linux commandline when using grub (by dropping a file in /etc/default/grub.d). I was asked to open a discussion about the general matter of a package tuning the Linux kernel command line options. I don't think it's a problem since it's in a package whose purpose is exactly that and it's easy to tune/disable if needed since it's in a configuration file, but in case people disagree feel free to reply (please keep me on CC, I'm not subscribed to -devel@). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlw8UR8ACgkQ3rYcyPpX RFtMuggA2H/+/cLT71cLzQVrkBy/yRsdpZ/2TRPn9akTP2BUUjlB3Ze/B5kBXFFT LnpfDap6/0RapExdPAmfGDEJnw0liV4jWfQy+g78VvKdoNUdqu5kqIB3tiY6pBnP yxLQZW/NMZTi+oM3sYK20PnyKWeN8eMfpNi5JAyUDELSXCPBMre9TrkAG9trnK+Y ilRWPV2p9BZQ7VlA8Psb9magXc9/O3r5dj9u9XdEjiyM5rtFl57gz+BFMfNOBRCI B4B4BWTyno/4y6+VK/tOl6ZmpVa5wuxk4VDHWZlRdCkPmWhrzezOIiNIZ58tPwAz KA2q1Z/+PbX4vSymzfdlW4BWUVa7Ag== =stla -END PGP SIGNATURE-
Bug#919268: ITP: libfsapfs -- APFS access library and utilities
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: libfsapfs Version : 20181215 Upstream Author : Joachim Metz * URL or Web page : https://github.com/libyal/libfsapfs * License : LGPL-3.0+ Description : APFS access library and utilities This is an indirect dependency of newer Plaso versions and will be maintained within the Debian Security Tools team
Re: Handling of entropy during boot
On Jan 13, Sam Hartman wrote: > I recently discovered that Vmware appears to have no virtual RNG > available to the guest at all. AFAIK you are right. > 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. Agreed. I think that d-i should install rngd (or haveged? And why?) if it detects a virtualized environment without virtio-rng. -- ciao, Marco signature.asc Description: PGP signature
Re: Handling of entropy during boot
On 12/18/18 8:11 PM, Theodore Y. Ts'o wrote: > If you are firmly convinced that there is a good > chance that the NSA has suborned Intel in putting a backdoor into > RDRAND, you won't want to use that boot option. I have read numerous times that some people trust this or that part of the instruction set, and I always found it silly. Why should some instruction or part of the Intel CPU be more trusted? To me, either you trust the entire CPU, or you just don't trust it at all and consider using other CPU brands. Am I wrong with this reasoning? Cheers, Thomas Goirand (zigo)
Bug#919278: ITP: golang-github-pquerna-ffjson -- faster JSON serialization for Go
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-pquerna-ffjson Version : 0.0~git20181028.e517b90-1 Upstream Author : Paul Querna * URL : https://github.com/pquerna/ffjson * License : Apache-2.0 Programming Lang: Go Description : faster JSON serialization for Go ffjson: faster JSON for Go Build Status (https://travis-ci.org/pquerna/ffjson) . ffjson generates static MarshalJSON and UnmarshalJSON functions for structures in Go. The generated functions reduce the reliance upon runtime reflection to do serialization and are generally 2 to 3 times faster. In cases where ffjson doesn't understand a Type involved, it falls back to encoding/json, meaning it is a safe drop in replacement. By using ffjson your JSON serialization just gets faster with no additional code changes. This package is going to be team maintained on salsa at https://salsa.debian.org/go-team/packages/golang-github-pquerna-ffjson This is my first golang package, so additional set of eyeballs would be appreciated. This package is a build-dependency of github.com/containers/image, which in turns is required for skopeo (#880199).
epoch for luakit versions
Hi, For the luakit package that I'm trying to get back into Debian, I'd like to use an epoch in the version. Here's the story: Originally (and still reflected on http://luakit.org), luakit used a date-based versioning scheme. In that, the last released version was 2017-08-10, which is what's currently being packaged. Meanwhile (and that's not yet reflected on luakit.org), there are releases on Github (https://github.com/luakit/luakit/releases) that follow a major.minor scheme, and the upstream maintainer has confirmed they want to keep that scheme in the future. As we bring these newer releases into Debian, we would like to reflect their version numbers in the Debian version number, too. Opinions? -- Markus
Re: epoch for luakit versions
On Mon, Jan 14, 2019 at 12:51:27PM +0100, Markus Demleitner wrote: > For the luakit package that I'm trying to get back into Debian, I'd > like to use an epoch in the version. > > Here's the story: Originally (and still reflected on > http://luakit.org), luakit used a date-based versioning scheme. In > > Meanwhile (and that's not yet reflected on luakit.org), there are > releases on Github (https://github.com/luakit/luakit/releases) that > follow a major.minor scheme, and the upstream maintainer has > confirmed they want to keep that scheme in the future. Sounds reasonable to me, with that being the original goal of epochs. However, please use 1: and not 2: like what upstream seems to have used… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#919279: ITP: node-terser -- parser/mangler/compressor for ES6+
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: node-terser Version : 3.14.1 Upstream Author : Mihai Bazon * URL : https://github.com/terser-js/terser * License : BSD-2-clause Programming Lang: JavaScript Description : parser/mangler/compressor for ES6+ Terser is a parser, mangler, optimizer and beautifier toolkit for ECMAScript 2015 and newer (ES6+). . terser is a fork of uglify-es that retains API and CLI compatibility with uglify-es (Debian packages node-uglify-js, libjs-uglify-js, and uglifyjs). . ECMAScript 2015 (ES2015) a.k.a. ECMAScript 6 (ES6) is the 6th formal definition of JavaScript - a high-level, interpreted programming language most notably used in web browsers and in Node.js. This package will be maintained in the JavaScript team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlw8ikUACgkQLHwxRsGg ASHEsQ//RYFko2WCpbeg7UBwzVASkf7gGZSkfJIU5T+XszydGfaH61ykkfmDEI6M Mm0tyd3ND7wugioEs+t9DwzPgpomKo+6xaap8AKaiNaK2KBmOcEmqg8gWJvONUIP eEitZ/ahRAA1mtxzG9S6/LQiOWDoe6Jo4iUPZpOBo2GlmlF9RJyTsgEyHibuVsqh iaPahIyKjVSzabMpnJAL7y6O5OO+CN2lw/+/YGHUjouL7yiPSuDLcd7Fsbso3hf6 +kib5miaokYZh8leergG3tuqsVlv1tGFYdbeje9lfj3wdUMrJVSx7qx4zKb79gs3 MeOA/HOoJhmpz6qJzQuNwZnaU7Hhx+2ajbSVGHdlmEoXAX8ANdn1Mf0/JpFIcjVv 20PocATunXBNbXnNjhfV3Z8+mo1gd6KrthV2KMyktx9GhVYjDrIW1Xj5VP+KMTi2 1XsXTYrt7FfMOdytY2FxnGzbva2sMElnoYB/+H4BQ996wY0nSytH9qPKN0P2+OVA VoEGBJlTLDFa32fi4vCsGz2RXKBDTpwSynTb0BsNlDeySL9OtLVv/8/3/+zwdcgX 91JLlgWuVcyIQteQ31QD+LgdsxHJ+Ctvaa3RwChrkczZgNqffFlZrouGEv4ROkrm /uXRPoFwB8WAkKfdgwb8Dbk3ff7C6KNAaq8K6jzS85eFNU/tB8o= =rYfc -END PGP SIGNATURE-
Re: epoch for luakit versions
On 2019-01-14 12:51 +0100, Markus Demleitner wrote: > Here's the story: Originally (and still reflected on > http://luakit.org), luakit used a date-based versioning scheme. In > that, the last released version was 2017-08-10, which is what's > currently being packaged. > > Meanwhile (and that's not yet reflected on luakit.org), there are > releases on Github (https://github.com/luakit/luakit/releases) that > follow a major.minor scheme, and the upstream maintainer has > confirmed they want to keep that scheme in the future. > > As we bring these newer releases into Debian, we would like to > reflect their version numbers in the Debian version number, too. > > Opinions? Yep. I think you need to use an epoch in this (classic) case. The learning from this is that if using date-based versioning due to lack an upstream versioning scheme (increasingly common in my experience), it's smart to use 0~$date so you can look smug and switch to (newer) versions if/when they adopt them without needed an epoch. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Handling of entropy during boot
On Mon, Jan 14, 2019 at 12:55:09PM +0100, Marco d'Itri wrote: Agreed. I think that d-i should install rngd (or haveged? And why?) if it detects a virtualized environment without virtio-rng. Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't really change anything. If it does support those, it probably makes more sense going forward to just enable CONFIG_RANDOM_TRUST_CPU rather than installing another package. As far as haveged, it's not clear how much better that is than the old practice of having rngd read from /dev/urandom. Mike Stone
Re: Re: Handling of entropy during boot
Sam Hartman wrote: "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. Another data point: there exist high-profile KVM-based cloud providers that don't give their customers a virtio RNG device in the guest. One particular example is AliYun, also known as Alibaba Cloud. Note that in some locations they provide Xen, not KVM, instances, so try Shanghai if you want to confirm my statement. -- Alexander E. Patrakov smime.p7s Description: S/MIME Cryptographic Signature
Re: Handling of entropy during boot
Quoting Michael Stone : Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't really change anything. If it does support those, it probably makes more sense going forward to just enable CONFIG_RANDOM_TRUST_CPU rather than installing another package. This option is only available for some architectures (X86, S390, PPC)? What about the others?
Re: Handling of entropy during boot
On January 14, 2019 11:56:20 AM EST, "W. Martin Borgert" wrote: >Quoting Michael Stone : >> Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't >> really change anything. If it does support those, it probably makes >> more sense going forward to just enable CONFIG_RANDOM_TRUST_CPU >> rather than installing another package. > >This option is only available for some architectures (X86, S390, PPC)? >What about the others? I'm not aware of a good general solution for them. -- Michael Stone (From phone, please excuse typos)
Bug#919299: ITP: flatpak-xdg-utils -- xdg-open and xdg-email reimplementation for containerized apps
Package: wnpp Severity: wishlist Owner: Simon McVittie * Package name: flatpak-xdg-utils Version : 0.1+ (git snapshot) Upstream Author : Florian Müllner, Matthias Clasen, Alex Larsson * URL : https://github.com/flatpak/flatpak-xdg-utils * License : LGPL-2+ Programming Lang: C Description : xdg-open and xdg-email reimplementation for containerized apps Applications running in a Flatpak sandbox cannot normally launch arbitrary subprocesses outside the container to open files and URLs. This package provides reimplementations of the standard xdg-open(1) and xdg-email(1) command-line tools intended to be run inside the container. They use the D-Bus session bus to communicate with the xdg-desktop-portal service outside the container. These tools are developed alongside Flatpak, but they are not completely Flatpak-specific, and might also be useful for other app-container technologies. This package is normally only useful if you are using Debian packages to construct a Flatpak runtime, and should not be installed on a normal Debian desktop system. On desktop systems please install the reference implementation of the xdg-open and xdg-email tools, which can be found in the xdg-utils package. If this package is installed in a non-Flatpak environment for testing, it will not work without the dbus-session-bus and xdg-desktop-portal packages. [X-Debbugs-Cc to xdg-utils maintainers for information: this will probably have Conflicts/Replaces, and possibly Provides, on the reference implementation of xdg-utils.] --- This will probably also produce a second binary package, flatpak-spawn or similar, with the parts that are completely Flatpak-specific: Package: flatpak-spawn Description: tool to run programs outside a Flatpak sandbox Applications running in a Flatpak sandbox cannot normally run arbitrary commands outside the container, and cannot create nested containers. The flatpak-spawn tool uses the D-Bus session bus to communicate with a portal service provided by Flatpak outside the container, which can run commands on behalf of the sandboxed application, subject to Flatpak permissions checks. . Applications that contain a helper tool such as a thumbnailer can use flatpak-spawn to launch that tool in a new instance of their own sandbox, with more restrictive permissions. For example, this can be used to mitigate possible security vulnerabilities in thumbnailers by granting fewer privileges to the thumbnailer. . Trusted applications with the 'devel' privilege flag, such as the GNOME Builder integrated development environment, can also use flatpak-spawn to run arbitrary commands on the host system, bypassing the sandbox. . This package is only useful if you are using Debian packages to construct a Flatpak runtime, and should not be installed on a normal Debian desktop system.
Bug#919313: ITP: r-cran-ffield -- Force field simulation for a set of points
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: r-cran-ffield Version : 0.1.0 * URL : https://cran.r-project.org/web/packages/FField/index.html * License : GPL-3 Programming Lang: R Description : Force field simulation for a set of points To be team-maintained at https://salsa.debian.org/r-pkg-team/r-cran-ffield
Re: Debian Bug Squashing Party in Montréal, Canada - January 19-20 2019
unsubscribe Am 2018-12-12 um 00:24 schrieb Louis-Philippe Véronneau: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 We are organising a BSP in Montréal in January! Unlike the one we organised for the Stretch release, this one will be over a whole weekend so hopefully folks from other provinces in Canada and from the USA can come. So yeah, come and squash bugs with us! Montreal in January can be cold, but it's usually snowy and beautiful too. As always, the Debian Project is willing to reimburse 100 USD (or equivalent) of expenses to attend Bug Squashing Parties. If you can find a cheap flight or want to car pool with other people that are interested, going to Montréal for a weekend doesn't sound that bad, eh? When: January 19th and 20th 2019 Where: Montréal, Eastern Bloc Why: to squash bugs! Link: https://wiki.debian.org/BSP/2019/01/ca/Montreal - -- ,''`. : :' : Louis-Philippe Véronneau `. `'` po...@debian.org / veronneau.org `- -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZ39U8fqGga2OwLzmeurE7GqqCpcFAlwQRzkACgkQeurE7Gqq Cpeu+w//YOeO1PNUSqDpts4PBukL1fud7JWuyrjOlvg+yVKD9Xtc97Dv5sJIjwdC +vI5mK6Zb88TtkLsePZfHP9vjOojaRhL15NnJ/4eujr94URx0IJfFGiHf8JZx2MT HA0nlWlzAstfyQHLAKsntBWeegKtQp/ilUtGhLKhIj8bK0xk7wFvqc+Z0XBBN5kh r0rrKNX6LT0PaBFm5glehWMuwVWz6yoDl+jEI+sEI1Z/GCq5Q+0/7bRONaRxcwSj doQV9g2171IfT4mFo2UHvF4B9VYP2OBgV1hxtJh22ZawqIi7BWmJsDl3iMXQaI+S kD3ILDMV5yMsp0tG7Mr0r1bmc5izYNGbMliw+Ta4QALZ3eO5vTERMn4TnOS71Of6 WlMkqY344kQbTPht0MYGmRWhb4Gcea3/y3wi+WKpEdltGhaboQuTkMCM+h/bKNdI Pl77RnyEewdo0QyVAc9vaLN7JGStVQK/fyzPZpCFyNMjNULCXYXDxMj1QfQ+6FK7 t6a9iml3AwjDmezwUyoCKvoqLUZndnpKmZLUlJTvEQbgu4FMtRXpBz2b7da87hEe qEd+4FM1MlerWhJbUxySwzcRD1uM1BKMlEKXiypumUDUGVNXDw8peEn7GtM7oJnJ ro6z/t+IZMBMBZOW81w2p/ZQrD8k5ArXIUV0YnZdJYsQWFrldls= =Ggoy -END PGP SIGNATURE-
Bug#919327: ITP: libexadrums -- Software drum module (library)
Package: wnpp Severity: wishlist Owner: Jeremy Oden * Package name: libexadrums Version : 0.3.0 Upstream Author : Jeremy Oden * URL : https://github.com/SpintroniK/libeXaDrums * License : MIT Programming Lang: C++ Description : Software drum module (library) ExaDrums is a virtual drum module that allows to play drums with custom-made drum kits. It is user-friendly and combines high quality stereo sound with low latency. Each drum kit provides individual sliders in order to control the volume of its drum pads. A built-in metronome can be combined with a rhythm coach to make practice sessions easier and efficient. The drum triggers can be adjusted so that their response feels as natural as possible, and different sensor interfaces include a virtual (on-screen) multi pad and external sensors. Libexadrums provides a C++ API that offers the functionalities of a standard drum module. I have played drums using libexadrums, and it is working well. To my knowledge there are no packages in the current Debian distributions that offer similar functionality.
Bug#919328: ITP: exadrums -- Software drum module (graphical user interface)
Package: wnpp Severity: wishlist Owner: Jeremy Oden * Package name: exadrums Version : 0.3.0 Upstream Author : Jeremy Oden * URL : https://github.com/SpintroniK/eXaDrums * License : MIT Programming Lang: C++ Description : Software drum module (graphical user interface) ExaDrums is a virtual drum module that allows to play drums with custom-made drum kits. It is user-friendly and combines high quality stereo sound with low latency. Each drum kit provides individual sliders in order to control the volume of its drum pads. A built-in metronome can be combined with a rhythm coach to make practice sessions easier and efficient. The drum triggers can be adjusted so that their response feels as natural as possible, and different sensor interfaces include a virtual (on-screen) multi pad and external sensors. Exadrums provides a graphical user interface that offers the functionalities of a standard drum module. I depends on libexadrums. I have played drums using exadrums as a drum module, and it is working well. To my knowledge there are no packages in the current Debian distributions that offer similar functionality.
Bug#919329: ITP: r-cran-venndiagram -- Generate High-Resolution Venn and Euler Plots
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: r-cran-venndiagram * URL : https://cran.r-project.org/web/packages/VennDiagram/ * License : GPL-2 Programming Lang: R Description : Generate High-Resolution Venn and Euler Plots To be team maintained at https://salsa.debian.org/r-pkg-team/r-cran-venndiagram
