Re: Packaging of static libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 11, 2016 at 03:25:46PM +0900, Mike Hommey wrote: > > What uses require PIC static libraries that cannot be satisfied by building > > -static --whole-archive ? > > https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-_-fPIE_-pie.29 That sounds convincing. So given that we want hardening for the entire archive, shouldn't we make PIC static libraries the default? And allow maintainers to provide a non-PIC version if they consider it useful? At the very least, I think policy should define whether static libaries are supposed to be PIC or not. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXC1ooAAoJEJzRfVgHwHE600IP/jMkEaYHQPen0pVqET6nExGm xTABDDSkaDKocAigz5wjICeYE8OJtxvVs5aO/scPPFq0Na/+UfmWm1v23omHIM5E BrzDyPUjwphFSq2JsAMRFVO9XYIRraEMDMxZuQDMoSZwuExT5HmRNOn4VTs0ceTu zXgQfTv8KOCLCFSRbkWxLdu8J+NyprAyOm4XCMq08PVeNIXgfXAohVGDRraDVdF+ HQgjROAhKje+ZDUM5aak/fMH7wqxUp0zyjKdb3IJ/solW3N/Ld2vsZdbCgxqlIvS Z17VkgI6/RFjzQhoj9ew8S31toXuqheNB5aAgON3Ocw5dbhJOuW9GHnrUzYY2oEK jFMJiDZWxfSMrydI0NVrn+6xks5FjyEhMTuhDF7deX7DMy9Qtlrwgj8GbA8G9o8/ rTUElQ6U9xI4BDSBYZjNzDqqgKHfcX/0bn4SX3QAj2Jps+M6pt+G2LIwHYJ8AJ+s vEtfbSxbQhbc+t6ZphB7NEcZhoWLlosA/OMASBjnlBxtxVJVR5F+0Q40idl7JBtR jN2Ex5rV18N4ibjWouBuuZ+Q628AgwGxKFvOkp+oN9J8gXBtt+fhMAf2UkG4NR5U 2mqP5/+QceM94nkoyyUnIohYy8NzEWMt69qsyay2pXeWfJdiavspNG/J7yc6sVVR Q9FuntLNnAr+dJiWoDwS =H+ms -END PGP SIGNATURE-
Re: gitlab package (was Re: Opt out style recommends)
On 2016-04-10 03:55, Pirate Praveen wrote: >> >> while i really appreciate all the work you are doing for the gitlab >> package, i honestly have the feeling that you are trying to make too >> many decisions on behalf of the system administrator who wants to >> install gitlab. > > I just want the service up and running after you install gitlab. Isn't it how > every other service doing it? yes sure. but if i install other web-services (e.g. php-horde) they don't bother me with setting up an enrypted webservice. the only reasonable package that should suggest ways of encrypting seems to be the webserver (apache2, nginx,...) > >> i really don't see any compelling reason why a package like gitlab >> should force me to use any special means to encrypt my connection. > > It does not. Even earlier with letsencrypt in depends, it asks in post > install if letsencrypt should be used. Now it is in recommends and you can > just skip letsencrypt. cool. thank you. >> there are a number of reasons to use the Debian gitlab packages over >> the >> ones provided by upstream (e.g. omnibus), and one of them is being able >> to chose the components i would like to have on my system (or not). > > It is just the first attempt and making all components optional is in my > todo. Patches to speed it up is welcome. > > nginx is already made optional in last update. Next is database. i see. since you were basically starting from this huge monolithic installation, it makes sense to first get the package running and then factor out as much as possible. > > Its already 8.5.8. Three new gems are required for 8.6 and we are already > working on it. > fantastic. famtsd IOhannes
Re: Priorities overrides? Extra?
On Sun, Apr 10, 2016 at 10:13:14PM +0200, Ole Streicher wrote: > >> Question is wich information they cover. For me, "optional" means: > >> conflict free by policy. > > You are still mixing two completely separate things. > Which? The existence of the override mechanism and the optional vs extra priority semantics. > > Changing overrides is a normal procedure. > For 12.000 packages? Sure, these are less if I leave out oldlibs and > debug packages, but probably still a few thousands. We may do this by implementing #759260. > >> For a field that is -- as you said -- pure informational (and where the > >> wrong setting could be mentioned just by filing a bug). > > By saying "informational" I meant that the override value is what matters, > > not the field in the package. > So what is the field in the package for? Well, it sets the initial value of the override. I think ideally it should be the primary source of this information but we are not there yet and I don't know if something is done in that direction. > >> Sure. The problem arises f.e. with my package: it is really special, and > >> you would not like to install it unless you know what it is for. > > You should use "optional" for such packages. > Sure. As there are hundreds of other packages which are in the blends. Well, either you are considering them buggy or you aren't. In the former case you may want to fix those bug, in the latter one you don't do anything with it. > >> > See also #759260 for discussions about dropping extra completely. > >> > >> I would not drop it completely, since it provides the useful information > >> "may have conflicts with other packages". > > I'm not sure who would find this information useful. > > Note that according to the bug discussion this distinction was caused only > > by a requirement to be able to co-install all optional packages which is > > not useful at all. > > "Optional" packages are conflict free by policy. So, if we provide a few > default installations of Blends via tasksel, we can be sure that there > will be no conflict, as long as all tasks are Priority "optional". I'm not sure a task that installs a lot of arbitrarily chosen unrelated packages is useful either. > The problem is not to install *all* packages, but to be able to install > *every* package without the risk of having a conflict (not sure if my > englisch is good enoough here): how else can I make sure that if someone > chooses at installation time that he wants to have f.e. "Debian Astro" > installed, that none of the included packages have conflicts? I thought the task of making a distribution out of a bunch of packages involves more than just running a script that show which packages can be coinstalled. > > You can also behave like many packagers do: don't pretend that optional > > and extra priorities are different and that the policy (still) has > > different requirements about them. I don't see any downsides with that. > > As I wrote: The distinction is good for things that are done by first > install. Imagine some newcomer who selects the "Debian Games" pure blend > during the Debian installation and is then left alone with the > resolution of package conflicts. I'd call that a desaster. I don't know how do pure blemnds work but it's obvious to me that this situation with resolving conflicts should not be possible. But I'm not sure it's a good idea to just trust priorities for that. -- WBR, wRAR
Re: gitlab package (was Re: Opt out style recommends)
On 2016, ഏപ്രിൽ 11 1:35:39 PM IST, "IOhannes m zmölnig (Debian/GNU)" wrote: >Isn't it how every other service doing it? > >yes sure. > >but if i install other web-services (e.g. php-horde) they don't bother >me with setting up an enrypted webservice. >the only reasonable package that should suggest ways of encrypting >seems >to be the webserver (apache2, nginx,...) > I think php-horde was packaged before Snowden revelations and letsencrypt. 1.Most people in the world including myself thought encryption was an optional thing two years back. 2.automating ssl was not possible before letsencrypt. Now you just need to click/press yes button to get an encrypted service running. And for those who do not want it, the default is 'no' for both ssl and letsencrypt. It would be a good time to add letsencrypt support to php-horde and every other service dealing with sensitive data like passwords. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: gitlab package (was Re: Opt out style recommends)
❦ 11 avril 2016 15:18 +0530, Pirate Praveen : > 2.automating ssl was not possible before letsencrypt. Now you just > need to click/press yes button to get an encrypted service running. > > And for those who do not want it, the default is 'no' for both ssl and > letsencrypt. > > It would be a good time to add letsencrypt support to php-horde and > every other service dealing with sensitive data like passwords. In this case, this could be done centrally, for example in the letsencrypt package. -- "... an experienced, industrious, ambitious, and often quite often picturesque liar." -- Mark Twain signature.asc Description: PGP signature
Re: gitlab package (was Re: Opt out style recommends)
]] Pirate Praveen > 1.Most people in the world including myself thought encryption was an > optional thing two years back. Is that why we've been pushing for SSH over telnet for twenty years now? > 2.automating ssl was not possible before letsencrypt. Now you just > need to click/press yes button to get an encrypted service running. I'd really like this to be an optional addon, since there's no way you could know how to integrate with how I acquire my certs. I also question whether it's the job of an application to set up certificates. Does that mean you're configuring various application servers (for vhosting) and TLS terminators too? > And for those who do not want it, the default is 'no' for both ssl and > letsencrypt. Minor comment, but hopefully you're asking about TLS and not SSL in any questions you ask the admin. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: gitlab package (was Re: Opt out style recommends)
On 2016-04-11 11:48, Pirate Praveen wrote: > It would be a good time to add letsencrypt support to php-horde and every > other service dealing with sensitive data like passwords. no, seriously not. i am all for having all web traffic encrypted. that's why the web-server package *may* push for encryption (by suggesting letsencrypt or whatever). however, it is none of the web-application's business. and gitlab is just that: a web-application. fgmsdr IOhannes
Re: gitlab package (was Re: Opt out style recommends)
On 2016, ഏപ്രിൽ 11 3:35:56 PM IST, Vincent Bernat wrote: >In this case, this could be done centrally, for example in the >letsencrypt package. With debhelper integration like we do for init scripts or systemd. If debian/.letsencrypt is present, it should take care of the remaining. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: gitlab package (was Re: Opt out style recommends)
On Mon, Apr 11, 2016 at 03:18:58PM +0530, Pirate Praveen wrote: > 1.Most people in the world including myself thought encryption was an > optional thing two years back. > > 2.automating ssl was not possible before letsencrypt. Now you just need to > click/press yes button to get an encrypted service running. The "normal" way this was done before letsencrypt was with the 'snake oil' local SSL CA/cert and self-signing. Obviously not suitable for production use, but perfectly fine for an initial install/testing; it is also simpler than worrying about talking to LE (especially in a postinst/root/possibly unattended context) and a more appropriate initial state for a private/corporate install.
Re: gitlab package (was Re: Opt out style recommends)
On 2016, ഏപ്രിൽ 11 3:44:09 PM IST, Tollef Fog Heen wrote: >Is that why we've been pushing for SSH over telnet for twenty years >now? I should clarify, importance of https and end to end encryption was not considered widely. There were a minority pushing for encryption. But is is more mainstream idea now. >I'd really like this to be an optional addon, since there's no way you >could know how to integrate with how I acquire my certs. I also >question whether it's the job of an application to set up >certificates. Does that mean you're configuring various application >servers (for vhosting) and TLS terminators too? It is optional. I do configure a site for nginx (add virtual host in /etc/nginx/sites-available). TLS is enabled when it is selected. I can make nginx configuration optional. >> And for those who do not want it, the default is 'no' for both ssl >and >> letsencrypt. > >Minor comment, but hopefully you're asking about TLS and not SSL in any >questions you ask the admin. Isn't that just semantics? OpenSSL is still not renamed to OpenTLS (yes there is gnuTLS). I think SSL term is still widely used referring to TLS. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#820689: ITP: subuser -- Run programs on Linux with selectively restricted permissions
Package: wnpp Severity: wishlist Owner: Stanislas Leduc Hey dear mentors, I am looking for a sponsor for my package "subuser" * Package name: subuser Version : 0.5.6-1 Upstream Author : Timothy Hobbs * URL : http://subuser.org/ * License : LGPL-3 Section : admin Programming Lang: Python Description : Run programs on Linux with selectively restricted permissions Furthermore, the fragmentation of the Linux desktop means that packaging work is needlessly repeated. Programs that build and run on Fedora must be repackaged for Ubuntu. This takes time away from creating great free open source software. Subuser with Docker attacks both problems simultaneously. Docker provides an isolated and consistent environment for your programs to run in. Subuser gives your desktop programs access to the resources they need in order to function normally. This package depend on docker.io, git and python3 Following my reading on linuxfr.org I discovered this project, it seems interesting and promising. So naturally I offered my help to package the application for Debian and CentOS / Redhat. I am in contact with the developer, for having exchanged with him for packaging on Debian, it is responsive and open. This is my first package for Debian, and think need sponsors to verify that package is compliant.
Re: Priorities overrides? Extra?
On 2016-04-10 19:50, Paul Wise wrote:
On Mon, Apr 11, 2016 at 5:49 AM, Philipp Kern wrote:
Maybe it's time to acknowledge that it's mostly busy work at this
point and packages could be authoritative for this kind of information
(and
handle NEW with a simple list of packages).
I expect the ftpteam will want to put things in NEW when they move
between main/contrib/non-free so a simple list of packages wouldn't be
enough?
Maybe. I'm not sure. main -> {contrib, non-free} could just work.
Elevating out of non-free would be problematic, of course. This could
also be implemented as a diff against the current state on import, it
wouldn't necessarily need to be in a list. But I don't really care. I
mostly care about sections without components and priorities. ;-)
Kind regards
Philipp Kern
Bug#820737: ITP: node-tar-pack -- Pack and unpack a Node.js module
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-tar-pack Version : 3.1.3 Upstream Author : Forbes Lindesay * URL : https://github.com/ForbesLindesay/tar-pack * License : BSD-2-Clause Programming Lang: JavaScript Description : Pack and unpack a Node.js module Handle modules tarballs with sane defaults. Pack filters out paths listed in .gitignore and other unwanted hidden files that can be found in a source directory. The resulting tarball should be extractable by npm, the Node.js package manager. Unpack fixes permissions and allows setting custom ownership. . Node.js is an event-based server-side JavaScript engine. This package is needed by node-pre-gyp, which is a build tool for Node.js binary addons.
Bug#820738: ITP: tiles-autotag -- Automatic tag generation for Apache Tiles
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: tiles-autotag Version : 1.1.0 Upstream Author : The Apache Software Foundation * URL : http://tiles.apache.org/tiles-autotag * License : Apache-2.0 Programming Lang: Java Description : Automatic tag generation for Apache Tiles Autotag generates tags (or tag-like) artifact from a common template code for a range of templating languages. JSP tags, Freemarker directive models and Velocity directives are generated from a common template model. tiles-autotag is a dependency of Tiles 3 required to upgrade the libspring-java package. I'll be maintained by the Java team.
Re: gitlab package (was Re: Opt out style recommends)
On Mon, Apr 11, 2016 at 3:41 AM, Jonathan Dowland wrote: > On Mon, Apr 11, 2016 at 03:18:58PM +0530, Pirate Praveen wrote: >> 1.Most people in the world including myself thought encryption was an >> optional thing two years back. >> >> 2.automating ssl was not possible before letsencrypt. Now you just need to >> click/press yes button to get an encrypted service running. > > The "normal" way this was done before letsencrypt was with the 'snake oil' > local SSL CA/cert and self-signing. Obviously not suitable for production use, > but perfectly fine for an initial install/testing; it is also simpler than > worrying about talking to LE (especially in a postinst/root/possibly > unattended > context) and a more appropriate initial state for a private/corporate install. > I feel like tossing in my two cents as well since this would likely impact me down the road... I'm also against a package such as gitlab (or drupal, wordpress, dokuwiki, etc.) trying to mess around with my TLS certificates. I'm also very much opposed to it even being a prompt during installation. I'm well aware that gitlab-ci is a beast (and a kludgy mess... god save your soul taking on that feller), but an initial installation should be getting things going and being out of the users face. In most situations, I would venture a guess that gitlab is sitting on internal servers and not publicly accessible. That kinda puts a damper on nice automated ssl with letsencrypt, doesn't it? (k.. not always, but in the typical situation) However, that old option with snakeoil... that still works in these environments. I personally use the letsencrypt infrastructure for some projects, but refuse to use their incredibly bloated client stuff. I use alternative client tools that suite my needs much better than the letsencrypt app does. If anything, shouldn't it be the web server (nginx, tengine, etc.) that would "suggest" letsencrypt? They won't recommend/suggest that package because SSL is a separate thing entirely. I would dare say, at this point, most admins that care about encryption also implement automation tools such as salt and ansible and already have well tested systems in place for certificates. In this particular case, I would suggest first making letsencrypt a Suggests. Then, I would suggest considering snakeoil for the https or just installing with http-only and providing a documented tool for moving to using letsencrypt. You and I both know that we're only talking about a web server configuration... shouldn't the web server be the one suggesting it? ... it doesn't because the web server packages consider SSL/TLS to be its own thing entirely that shouldn't be mixed in with other package deployments. tl;dr .. my opinion: letsencrypt should be a suggests; gitlab should do either https or do a self-signed cert; and letsencrypt integration should come post-install Just my opinions/thoughts. :)
