Re: Declarative packaging (Was: Re: Intended MBF: maintainer scripts not using strict mode)
On Thu, Jun 29, 2017 at 12:34 AM, Michael Biebl wrote: > The common expectation in Debian is, that we expect packages to be > "usable" after installation. Which means we often intermix installation > with configuration, which is typically done via maintainer scripts. > > This makes it very hard to disentangle those steps. We are re-implementing hacking around this entanglement in multiple places (Debian Live, OpenStack images, cloud-init etc), but only for a limited portion of the archive and only via manually munging the filesystem after install. This is also preventing us from having "OEM installs" where an hardware vendor can create a generic disk image and each boot of that image would run the necessary first-boot setup (like creating OpenSSH keys or prompting to create users). IIRC last time we discussed this, the recommendation was to set an environment variable that maintainer scripts could check to determine if they should do host-specific actions or just generic actions common to all hosts. Personally I think that seems like a bit of a hack and there needs to be a new state for packages to be in added to dpkg. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Subject: UMASK 002 or 022?
On Thu, Jun 29, 2017 at 12:21 AM, gwmfms6 wrote: > Paul, you seemed to indicate that you were able to set a different "user > default" umask in Stretch that's respected by gnome apps like gedit? No, I didn't indicate that. See my other reply for clarification. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#866334: ITP: lean -- theorem prover from Microsoft Research
Package: wnpp Severity: wishlist Owner: Benjamin Barenblat * Package name: lean Version : 3.2.0 Upstream Author : Leonardo de Moura et al. * URL : https://leanprover.github.io/ * License : Apache-2.0 Programming Lang: C++ Description : theorem prover from Microsoft Research Lean is a theorem prover or interactive proof assistant. That is, it’s a system in which you can write formal mathematical proofs that are checked for correctness by the computer. Lean is thus broadly similar to Coq, but the Lean developers hope to build a faster, more extensible system than Coq is today. From the About page: “Lean is a new open source theorem prover being developed at Microsoft Research, and its standard library at Carnegie Mellon University. Lean aims to bridge the gap between interactive and automated theorem proving by situating automated tools and methods in a framework that supports user interaction and the construction of fully specified axiomatic proofs. The goal is to support both mathematical reasoning and reasoning about complex systems, and to verify claims in both domains.” Lean has been under development for several years; regular releases first appeared in January. I use Lean, and I know other Debian users would like to have it easily accessible.
Re: alioth replacement survey
On 2017-06-28 21:26:56 +0200 (+0200), Alexander Wirt wrote: [...] > https://people.debian.org/~formorer/Survey.pdf - preliminary results. > I will close the poll on monday. I didn't take the survey since I only very rarely interact with Alioth to begin with, but I have to agree with the many comments on Q5 that it's unnecessarily conflating open core business models and contributor license agreements. The latter come in many varieties and, while a number of them may demand copyright assignment or relicensing permission, others are simply tools intended to reinforce the terms of the stated free and open licenses used by some projects. I'm not personally a fan of CLAs as they add bureaucratic overhead, slow down the new contributor process for a project and can in some cases scare away new contributors who are loathe to enter into "legal agreements" (and even though I am not a lawyer, I've been told by lawyers that submitting code under a copyright license is also entering into a legal agreement). However, CLAs like the one used by the Eclipse Foundation are not even close to the same level of concern for me as ones like Gitlab employs: https://eclipse.org/legal/CLA.php -- Jeremy Stanley
Bug#866316: ITP: svgpp -- SVG-framework with parsers for various syntaxes and adapters
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: svgpp Version : 1.2.3 Upstream Author : Oleg Maximenko * URL : https://github.com/svgpp/svgpp * License : Boost Programming Lang: C++ Description : SVG-framework with parsers for various syntaxes and adapters The library can be thought of as a framework, containing parsers for various SVG syntaxes, adapters that simplify handling of parsed data and a lot of other utilities and helpers for the most common tasks. SVG++ features * Is a header-only library * Can be used with any XML parser * Compile time configured - no virtual functions * Minimal runtime overhead - you pay only for what you get * Fully functional, conforming SVG viewers * Simple in-app SVG rasterizers * Import modules of vector editing software * Implementing path-only input of SVG format with minimal efforts in any graphics or math software * Compatible with C++03, but requires conforming implementation The package will be hosted on collab-maint. Anton
Re: Subject: UMASK 002 or 022?
My thinking in advocating for OTHER being 7 (ie, 027 or 077) was that
the incidents when someone wants OTHER to have access to their files are
fewer than when they do not want OTHER to have access. Do users
generally want OTHER to be able to read all their files? Or do they have
a particular set of files that they want OTHER to be able to
access/read? In this context it makes more sense to me to put the burden
on adjusting those specific files that the user wants OTHER to have
access to instead of having them that way by default. Having to adjust
those specific files also reinforces to the user what they are doing
(ie, they are giving the world access to those particular files).
On 2017-06-28 07:25, Ian Jackson wrote:
Paul Wise writes ("Re: Subject: UMASK 002 or 022?"):
On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote:
> This discussion should be on whether to set a default UMASK of 077 or 027.
I think the appropriate default umask is 077 due to the possibility of
some sites not naming the primary group of each user after the user.
The appropriate default umask is 002 if the user's primary group is
named after the user, or 022 otherwise.
If only we had some kind of automated information processing equipment
which could collect necessary inputs and then make correct decisions.
Ian.
Re: alioth replacement survey
On Mon, 19 Jun 2017, Wouter Verhelst wrote: Hi, > On Mon, Jun 19, 2017 at 01:49:36PM +0500, Andrey Rahmatullin wrote: > > On Mon, Jun 19, 2017 at 09:47:30AM +0100, Jonathan Dowland wrote: > > > Is it possible to share a link to the survey results? I saw it when I > > > submitted > > > my entry, but I closed the window before my brain parsed it, so I can't > > > retrieve > > > it without submitting the survey again, skewing the results (and I don't > > > want to > > > do that). > > That link only contains the number of sumbissions. > > Nevertheless, that might be interesting information. > > https://poll.snow-crash.org/index.php/statistics_user/action/surveyid/499767/language/en https://people.debian.org/~formorer/Survey.pdf - preliminary results. I will close the poll on monday. Alex
Bug#866242: ITP: node-editor -- Launch the $EDITOR in your program.
Package: wnpp Severity: wishlist Owner: saravanan30erd X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-editor Version : 1.0.0 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/node-editor * License : Expat Programming Lang: JavaScript Description : Launch the $EDITOR in your program Launch the $EDITOR (or opts.editor) for file. When the editor exits, cb(code, sig) fires. . This library is a dependency of npm, Node.js package manager. . Node.js is an event-based server-side JavaScript engine.
Re: Subject: UMASK 002 or 022?
Paul, you seemed to indicate that you were able to set a different "user default" umask in Stretch that's respected by gnome apps like gedit? How did you do it? On 2017-06-28 09:21, Paul Wise wrote: On Wed, Jun 28, 2017 at 7:25 PM, Ian Jackson wrote: The appropriate default umask is 002 if the user's primary group is named after the user, or 022 otherwise. AFAICT, neither of these achieve what the initiator of the thread wants to achieve; no read access by other users to one's files on multi-user systems by default.
Re: Declarative packaging (Was: Re: Intended MBF: maintainer scripts not using strict mode)
Am 27.06.2017 um 09:34 schrieb Niels Thykier: > After this, we need something other than triggers. Triggers are great > for regenerating global caches but they are not good at delegating > targeted functionality out like: > > * This package needs user X to be created dynamically with home set >to H with login shell S. systemd provides a facility called systemd-sysusers which allows to describe system user accounts declaratively. Maybe we could leverage that. https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html > * This package wants to enable and start service Y, but obviously first >after creating user X (which the service runs as) Related to that, there is systemd-preset https://www.freedesktop.org/software/systemd/man/systemd.preset.html If that would work for Debian is unclear to me. The common expectation in Debian is, that we expect packages to be "usable" after installation. Which means we often intermix installation with configuration, which is typically done via maintainer scripts. This makes it very hard to disentangle those steps. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Subject: UMASK 002 or 022?
On Wed, Jun 28, 2017 at 8:59 PM, gwmfms6 wrote: > You didn't notice because you run umask from your shell configuration? I should clarify, I meant bash shell not gnome-shell. > In other words, you have a working umask in Stretch? In my terminals yes, but not in apps launched from the GUI. > Can you tell me how to "run `umask 027` from my shell configuration"? I have the equivalent of this: echo 'umask 027' >> ~/.bashrc > Currently, I have not found a way to get gnome to respect umask setting in > Stretch. No idea how to do that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Subject: UMASK 002 or 022?
You didn't notice because you run umask from your shell configuration? In other words, you have a working umask in Stretch? I want a working umask in stretch. Can you tell me how to "run `umask 027` from my shell configuration"? Currently, I have not found a way to get gnome to respect umask setting in Stretch. On 2017-06-28 00:14, Paul Wise wrote: I had "UMASK 027" in /etc/login.defs and I didn't notice that this no longer works because I also run `umask 027` from my shell configuration. If you can track down why this no longer works, please file a bug about it and convince the maintainer to fix it in stretch.
Re: Subject: UMASK 002 or 022?
Setting umask in ~/.profile on Jessie works for me. On 2017-06-28 01:04, Arto Jantunen wrote: It doesn't work since pam_umask isn't run by default. However as far as I know this has been the case for a very long time (the oldest install I can check quickly is squeeze and it has the same issue).
Re: Intended MBF: maintainer scripts not using strict mode
2017-06-27 21:18 GMT+02:00 Ralf Treinen : > Hello, > > On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote: > >> we currently have in sid 84 maintainer scripts not using strict mode. >> That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > > Thanks to everybody for your feedback. I guess I will stick with > severity=normal for the moment. The MBF template, list of offending > maintainer scripts, and dd-list are attached. Note that I incidentally fixed samba and samba-common-bin in the not yet uploaded: https://anonscm.debian.org/cgit/pkg-samba/samba.git/commit/?id=e8564b1bebf8c3f2d8a4316c3aa933765ca2211e Regards -- Mathieu Parent
Re: Replacing apt's http method (dropping curl)
On Wed, Jun 28, 2017 at 02:56:50PM +0200, Tim Rühsen wrote:
> Hi,
>
> I just want to mention that libwget[1] already has all the code you need
> plus lot's of other fancy TLS stuff (session resumption, false start,
> tcp fast open, OCSP). It is part of GNU Wget2, which is not released
> yet, mainly because we want to wait for our GSOC student's work. But we
> can do an alpha release if that helps.
Well, we do already have a hugely battle tested http layer, so
we're really just adding a TLS layer to it (which is about 400
lines or). What is missing is just support for CONNECT proxies
really (well, and encrypted proxies, but that's easy).
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Re: Subject: UMASK 002 or 022?
On Wed, Jun 28, 2017 at 7:25 PM, Ian Jackson wrote: > The appropriate default umask is 002 if the user's primary group is > named after the user, or 022 otherwise. AFAICT, neither of these achieve what the initiator of the thread wants to achieve; no read access by other users to one's files on multi-user systems by default. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Replacing apt's http method (dropping curl)
On 06/27/2017 08:00 PM, Julian Andres Klode wrote: > Hi everyone, > > as we discussed before in IRC, we plan to eventually replace > our existing curl-based https method with our http method, > by adding TLS support to it. This will move HTTPS support > into apt proper, removing the apt-transport-https package. > > I'm not sure how long this will take, I hope we get something > useful next month. > > Rationale > = > * The https method is split out of apt because curl has a lot > of dependencies (29 vs 7 on my test setup, 15.9 vs 4 MB of > disk space) > * We want https to be a default these days, even if it provides > only minor security improvements. > * Our http method is actually tested a lot because it is the > default and supports advanced features, the https method just > does curl easy stuff sequentially. > > Transition plan > === > I plan to do this in two stages, both of which I expect to > happen in unstable if all features have been implemented > quickly. There might be feature-incomplete alphas in > experimental. > > In the first stage, the "https" method is renamed to > "https+curl", and a https->http symlink is added in apt. > > If no significant regressions are reported (we might drop > some options or increase some checks), and the package has > been in testing for some time, the apt-transport-https > package is removed. > > This ensures that (a) we get proper testing and (b) users > have a workaround if something fails in that testing period. > > Implementation > == > I so far implemented basic https support using GnuTLS, including > SNI and certificate validation, and one (!) local CA file (as our > tests need that). The code is incredibly hacky right now. And > https->http redirects don't work yet. > > Alternatives would be to use libnss or openssl. In the latter > case, we'd have to build a separate helper binary that does not > link to the GPLed code, and just unwraps a TLS connection into > a pipe (similar to stunnel) - we could also use a helper generally, > it would allow us to run the TLS stack as nobody (!!!) [OK, > we have to open the socket in the parent process and pass it > down to the TLS stack, so _apt opens the connection for firewalls]. > > The existing shitty proof of concept is available on GitHub: > > https://github.com/Debian/apt/compare/master...julian-klode:feature/http-https?expand=1 > > But as I said it's ugly. It also does not yet link the http > binary to the https binary. Hi, I just want to mention that libwget[1] already has all the code you need plus lot's of other fancy TLS stuff (session resumption, false start, tcp fast open, OCSP). It is part of GNU Wget2, which is not released yet, mainly because we want to wait for our GSOC student's work. But we can do an alpha release if that helps. The dependencies are quite low, most stuff is build-configurable (e.g. IDN, PSL, HTTP/2, HTTP compression support which is gzip+deflat e via libz, lzma/xz, bzip2, brotli). I see no problem if you like to cut stuff out (it is GPLed), that has of course pros and cons. I am also open to split out the needed code/API into a separate library. We are not planning to support anything but GnuTLS for TLS (it perfectly fit our needs and we are in close contact to the maintainer). We already have a good test suite, pretty good code coverage and also started fuzzing code, locally and via OSS-Fuzz. There is much more to say... but have a look yourself, think about it and feel free to contact me for questions and/or help. With Best Regards, Tim [1] https://gitlab.com/gnuwget/wget2 signature.asc Description: OpenPGP digital signature
Re: Subject: UMASK 002 or 022?
Paul Wise writes ("Re: Subject: UMASK 002 or 022?"):
> On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote:
> > This discussion should be on whether to set a default UMASK of 077 or 027.
>
> I think the appropriate default umask is 077 due to the possibility of
> some sites not naming the primary group of each user after the user.
The appropriate default umask is 002 if the user's primary group is
named after the user, or 022 otherwise.
If only we had some kind of automated information processing equipment
which could collect necessary inputs and then make correct decisions.
Ian.
Re: Declarative packaging
Niels Thykier, 2017-06-27 07:34:00 + : [...] > After this, we need something other than triggers. Triggers are great > for regenerating global caches but they are not good at delegating > targeted functionality out like: > > * This package needs user X to be created dynamically with home set >to H with login shell S. > > * This package wants to enable and start service Y, but obviously first >after creating user X (which the service runs as) > > * The user X also needs to own a few files or directories at location >Z (possibly including the home directory H). Ideally, this should >be done before starting the service Y. Sounds like embedding something Puppet-like in dpkg… Declarative, with dependencies (and triggers), yet with potential for dynamic stuff. Roland. -- Roland Mas Indépendant en informatique libre -- Free software freelance http://www.gnurandal.com/
Subject: UMASK 002 or 022?
I'd like to know why giving the world (Other) read access is even under consideration. If user wants a file to have Other readability this should be on the user to set it, but it should not be the default. What is the justification that every user be able to read every other user's documents? This discussion should be on whether to set a default UMASK of 077 or 027. NOTE: this discussion is made all the more important currently because it seems impossible to set a UMASK at all on Debian Stretch. None of the usual ways work within gnome on Debian Stretch. Can anyone comment on this fact? How does one get gnome to respect the umask value that's set in ~/.profile? Or if not ~/.profile where does one set the default umask value for gnome?
Re: Subject: UMASK 002 or 022?
Hi, On 27.06.2017 19:11, gwmf...@openmailbox.org wrote: > I'd like to know why giving the world (Other) read access is even under > consideration. If user wants a file to have Other readability this > should be on the user to set it, but it should not be the default. That can be solved by excluding people from the directory the files are in -- in order to access a file, all directories on the way there need to have at least 'x' permission for the current user. So, an umask of 022 and having each user in a single-member primary group gives the user all options: - To make your home directory completely private, chmod it to 750 (the group permissions don't matter really, because there is no one else in the group). - To allow other users to pass through your home directory (e.g. the webserver on the way to ~/public_html), chmod your home to 751. - To create a directory that a group of users may write to, use chgrp and then set permissions to 2770 (or 2775, if others should also be able to read). The Debian installation used to ask whether home directories should be private by default, IIRC that question still exists but is too low priority to be shown outside of expert mode. You can use dpkg-reconfigure adduser to set this up, then new user home directories will be created with 750 permissions. This method allows a one-time setup of desired behaviour, while the umask would need to be set at every login, and if it weren't set up correctly, this would lead to files having the wrong permission with no warning -- that's why it's more robust to just create files as readable for others and lock them out of the entire home directory. > What is the justification that every user be able to read everyone > else's documents? That depends on your use case. At university, we generally left the home directory open, and kept a separate ~/private directory with restrictive permissions, because it allowed us to easily share non-private files by just telling people to get them from our home directories. Simon signature.asc Description: OpenPGP digital signature
Re: Subject: UMASK 002 or 022?
Paul Wise writes: > On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote: > >> I'd like to know why giving the world (Other) read access is even under >> consideration. If user wants a file to have Other readability this should be >> on the user to set it, but it should not be the default. > > I expect for most Debian deployments this isn't that relevant, since > most are either servers with no real users or single-user systems with > no guest account. > >> What is the justification that every user be able to read everyone else's >> documents? > > This decision was made in the mists of time and has never been questioned. > >> This discussion should be on whether to set a default UMASK of 077 or 027. > > I think the appropriate default umask is 077 due to the possibility of > some sites not naming the primary group of each user after the user. 077 is poor choice of default given that we decided to have users in their own dedicated group precisely to allow more generous group permissions, and if someone decides to deviate from that policy they need to take care of the consequences of their actions. In case anyone is wondering why we have users in their own group is it to allow one to create shared group directories, with the group s-bit set, so that anyone in that group can create files in that directory. If one has a 077 umask, that results in files in s-bit directories being created that only the creator can read, which is almost certainly not what you wanted. To fix that, one sets a umask of something like 027 or 022 or 002 depending on your needs, but on traditional *nix systems all users would generally be in a users or staff group, so you just gave overly-permissive access to your home directory by doing that -- hence the dedicated per-user groups. > That said, 027 would probably be a reasonable default too since most > sites do not do that. I think 027 is much easier to justify, is seems likely that anyone that prefers 022 over 027 is more likely to know why. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#866196: ITP: ruby-asciidoctor-plantuml -- extension for Asciidoctor to enable support for PlantUML diagrams
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-asciidoctor-plantuml Version : 0.0.7 Upstream Author : Pepijn Van Eeckhoudt * URL : https://github.com/hsanson/asciidoctor-plantuml * License : Expat Programming Lang: Ruby Description : extension for Asciidoctor to enable support for PlantUML diagrams This package provides asciidoctor-plantuml gem which is an extension for the asciidoctor gem that enables users to add PlantUML diagrams to their asciidoc documents.
