Re: Buster/XFCE unlock screen is blank
Hi Russ, all, On 19-06-01 11:04:28, Russ Allbery wrote: > I did some research on that a while back and ended up not filing a bug > about it because it looked relatively pointless. It appeared to be a > deep design choice on both sides, and not something anyone was likely > to solve, so I just switched to a desktop-aware locker. If I may ask, which one? Cheers, Georg signature.asc Description: PGP signature
Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
Hi, On 19-07-26 17:17:02, Bastian Blank wrote: > Why do you think we would change it _if_ this option would exist? Because, chances are, you want to test if the package builds fine, for example, instead of running the upstream CI config. (Yes, I'm aware that it's possible to make this change per repo.) Cheers, Georg
Bug#1014814: ITP: onionprobe -- test/monitor tool for Tor Onion Services sites
Package: wnpp Owner: Georg Faerber Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-privacy-maintain...@lists.alioth.debian.org Package name: onionprobe Version : 1.0.0 Upstream Author : Silvio Rhatto URL : https://gitlab.torproject.org/tpo/onion-services/onionprobe License : GNU General Public License v3 Programming Lang: Python Description : test/monitor tool for Tor Onion Services sites Onionprobe is a tool for testing and monitoring the status of Tor Onion Services sites. It can run a single time or continuously to probe a set of onion services endpoints and paths, optionally exporting to Prometheus. This package will be maintained within the Debian Privacy Tools Maintainers team.
Bug#1024594: RFP: nginx-unit -- polyglot app server, a reverse proxy, and a static file server
Package: wnpp Owner: Georg Faerber Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org Package name: nginx-unit Version : 1.28.0 Upstream Author : Nginx team members and contributors URL : https://github.com/nginx/unit License : Apache Software License (ASL) 2.0 Programming Lang: C Description : polyglot app server, reverse proxy, and static file server nginx-unit is a lightweight and versatile open-source server that has three core capabilities: * it is an HTTP reverse proxy, * a web server for static media assets, * and an application server that runs code in seven languages. Key Features Flexibility * The entire configuration is managed dynamically over HTTP via a RESTful JSON API * Updates to the configuration are performed granularly at runtime with zero interruption * Requests are routed between static content, upstream servers, and local apps * Request filtering and dispatching uses elaborate matching rules that allow regular expressions * Apps in multiple languages and language versions run side by side * Common language-specific APIs for all supported languages run seamlessly * Upstream server groups provide dynamic load balancing using a weighted round-robin method * Originating IP identification supports X-Forwarded-For and similar header fields Performance * Requests are asynchronously processed in threads with efficient event loops (epoll, kqueue) * Syscalls and data copy operations are kept to a necessary minimum * 10,000 inactive HTTP keep-alive connections take up only a few MBs of memory * Router and app processes rely on low-latency IPC built with lock-free queues over shared memory * Built-in statistics provide insights into Unit’s performance * The number of per-app processes is defined statically or scales preemptively within given limits * App and instance usage statistics are collected and exposed via the API * Multithreaded request processing is supported for Java, Perl, Python, and Ruby apps Security & Robustness * Client connections are handled by a separate non-privileged router process * Low-resource conditions (out of memory or descriptors) and app crashes are handled gracefully * SSL/TLS with SNI, session cache and tickets is integrated (OpenSSL 1.0.1 and later) * Different apps are isolated in separate processes * Apps can be additionally containerized with namespace and file system isolation * Static file serving benefits from chrooting, symlink and mount point traversal restrictions Supported App Languages * Binary-compiled languages in general: using the embedded libunit library * Go: by overriding the http module * JavaScript (Node.js): by automatically overloading the http and websocket modules * Java: using the Servlet Specification 3.1 and WebSocket APIs * Perl: using PSGI * PHP: using a custom SAPI module * Python: using WSGI or ASGI with WebSocket support * Ruby: using the Rack API Upstream docs available via https://unit.nginx.org/.
Re: Master-Slave terminology
Hi Ulrike, all, On 20-02-12 17:46:15, Ulrike Uhlig wrote: > I'd like to attract your attention to this very fine document: > > https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1 > > Quoting from there: "Master-slave is an oppressive metaphor that will > and should never become fully detached from history." Thanks for raising awareness on this topic. Cheers, Georg
Spam targeting nnn-done@bugs.d.o
Hi, Just to let people know: Recently, there has been quite some spam with identical content sent to different bugs, project and team mailing lists, etc. That's bad, but what's even more worse is that this spam now gets send to nnn-done@bugs.d.o (see [1] for an example), in fact closing bug reports. Just pointing this out here to make people aware and (maybe) to discuss what could be done regarding this. All the best, Georg [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497825#113 signature.asc Description: Digital signature
Re: Spam targeting nnn-done@bugs.d.o
On 18-02-21 18:31:46, Sven Joachim wrote: > On 2018-02-21 17:48 +0100, Georg Faerber wrote: > > Just to let people know: Recently, there has been quite some spam > > with identical content sent to different bugs, project and team > > mailing lists, etc. That's bad, but what's even more worse is that > > this spam now gets send to nnn-done@bugs.d.o (see [1] for an > > example), in fact closing bug reports. > > That's not a new phenomenon, it has been happening for many years: > > https://lists.debian.org/debian-devel/2004/03/msg00847.html > https://lists.debian.org/debian-devel/2008/09/msg00124.html Thanks, wasn't ware of this. signature.asc Description: Digital signature
wiki.d.o returns "403 Forbidden"
...at least for me. Could someone forward this to DSA? (I would have contacted them directly via ITC, but currently traveling without access to IRC.) Thanks, Georg signature.asc Description: Digital signature
Re: Spam targeting nnn-done@bugs.d.o
Hi Don, On 18-02-21 10:53:49, Don Armstrong wrote: > Speaking on behalf of owner@, we're always looking more assistance in > creating better SA rules. Our configuration is publicly available.[1] > [I've just started moving it from alioth to salsa, so the git urls will > change slightly.] Thanks for sharing the repo. Regarding external contributions: Do you / the team prefer MRs, reports via the BTS with an attached patch, or something else? Cheers, Georg signature.asc Description: Digital signature
FHS: Where to store user specific plugins / code
Hi Debian Developers, all, I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list manager with resending-capabilities". Currently, we allow users to run / execute their own plugins, stored in /etc/schleuder/plugins. Obviously, that's not the right place, as /etc is for config files, not executable code. We would like to fix this, but are unsure which location to offer. The (empty) directory would be provided by the package, but the (possible) content would be provided by the user. Therefore, I'm wondering what's the correct place: Would /usr/local/lib/schleuder/plugins be sensible? If not, any other place which is more suitable? Looking forward to your input! All the best, cheers, Georg [1] https://tracker.debian.org/pkg/schleuder signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
Hi all, Thanks for your replies, and sorry for the delay in answering. (Note to myself: Don't write such mails while traveling..) That said, I think I wasn't clear regarding "user specific": On 18-02-28 18:54:14, Georg Faerber wrote: > Currently, we allow users to run / execute their own plugins, stored > in /etc/schleuder/plugins. Obviously, that's not the right place, as > /etc is for config files, not executable code. We would like to fix > this, but are unsure which location to offer. The (empty) directory > would be provided by the package, but the (possible) content would be > provided by the user. > > Therefore, I'm wondering what's the correct place: Would > /usr/local/lib/schleuder/plugins be sensible? If not, any other place > which is more suitable? Using "user" I meant not the real "end-users", sending mail, but the "user" (an admin running a mailserver) who installs schleuder. Cheers, Georg signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
Hi, On 18-03-01 07:55:08, Peter Silva wrote: > -- it is best practice for daemons/services not to run as root. They > should have an application specific user. Schleuder does use a dedicated user, called schleuder. $HOME is set to /var/lib/schleuder. Inside there mailing list specific data is stored. Cheers, Georg signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
Hi, On 18-02-28 18:14:17, Marvin Renich wrote: > If a user get to install his/her own plugins, they should go in the > user's home directory, e.g. /home/user/.config/scheduler/plugins/. > Non-root users should not generally be given write permission to > /usr/local, and definitely not to /usr/lib. See my separate mail: The term "user" used by me was misleading, I guess, more appropriate would have been "admin". > If the app takes care of installing the plugins on the user's behalf, > that is slightly different. However, if the plugin can be selected by > the user from a non-trusted source, I would still go with the user's > directory. Allowing a non-root user to put his own plugin where > others can execute it without being able (even required) to verify its > integrity is a huge security hole. The app doesn't take care of installing the plugins. This would be the job of the admin, using whichever technique they're comfortable with. > Ian's comments are good for admin-installed plugins that the users can > use. In fact there is good precedent for an app checking > /usr/lib/pkg/... for plugins installed from Debian packages, > /usr/local/lib/pkg/... for plugins installed by the admin from > non-Debian locations, and then finally the user's .config/pkg/... > directory. I guess we'll go with /usr/local/lib/schleuder then? Does this sound like a reasonable choice? Thanks, Georg signature.asc Description: Digital signature
Re: FHS: Where to store user specific plugins / code
Hi Jonas, On 18-03-09 19:18:50, Jonas Meurer wrote: > Am 09.03.2018 um 14:23 schrieb Georg Faerber: > >> Ian's comments are good for admin-installed plugins that the users can > >> use. In fact there is good precedent for an app checking > >> /usr/lib/pkg/... for plugins installed from Debian packages, > >> /usr/local/lib/pkg/... for plugins installed by the admin from > >> non-Debian locations, and then finally the user's .config/pkg/... > >> directory. > > > > I guess we'll go with /usr/local/lib/schleuder then? Does this sound > > like a reasonable choice? > > I don't think it's allowed for Debian packages to create subdirectories > under /usr/local, is it? According to the policy, that's allowed [1]: "As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. However, the package may create empty directories below /usr/local so that the system administrator knows where to place site-specific files. These are not directories in /usr/local, but are children of directories in /usr/local. These directories (/usr/local/*/dir/) should be removed on package removal if they are empty. Note that this applies only to directories below /usr/local, not in /usr/local. Packages must not create sub-directories in the directory /usr/local itself, except those listed in FHS, section 4.5. However, you may create directories below them as you wish. You must not remove any of the directories listed in 4.5, even if you created them." Cheers, Georg [1] https://www.debian.org/doc/debian-policy/#site-specific-programs signature.asc Description: Digital signature
Re: Bug#895253: ITP: elisa -- Simple music player with a focus on Plasma desktop integration and privacy
Hi, On 18-04-09 01:28:32, Marco d'Itri wrote: > Maybe the developers of these program should implement some call-home > functionality to collect metrics about which features are actually > used by their users, to be able to better tune the default settings? Please don't ask upstreams to implement such features; IMHO, adding more "call-home functionalities" to collect user data (even if anonymized) isn't a wise idea, especially in these times.. Cheers, Georg signature.asc Description: Digital signature
Re: ed25519 keys and mentors.d.n
Hi, On 18-04-08 17:29:17, Daniele Nicolodi wrote: > On 08/04/2018 17:10, Mattia Rizzolo wrote: > > On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote: > >> I just tried to upload a package to mentors.debian.net and it got > >> rejected because is is signed with an ed25519 key: > >> > >> gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D > >> gpg: Can't check signature: unknown pubkey algorithm > >> > >> I guess the infrastructure has not been upgraded to GnuPG 2. > > > > Yes, when we upgraded the host 1,5 months ago we tried also moving > > to gpg2, but that wasn't as straightforward as we'd hoped… So, we've > > installed gnupg1 and changed the binary used. > > > > Patches welcome, as usual :) > > I can look into that. What code needs to be patched? Have a look at [1] to begin with. Cheers, Georg [1] https://salsa.debian.org/mentors.debian.net-team/debexpo/blob/live/debexpo/lib/gnupg.py signature.asc Description: Digital signature
Re: Music player & privacy (was: ITP: elisa)
On 18-04-12 01:05:46, W. Martin Borgert wrote: > On 2018-04-11 07:41, Paul Wise wrote: > > Is anyone interested in facilitating a privacy-team BoF at > > DebConf18? > > Yes. Would you schedule/organise it? I'm pretty sure, that many people > will join, who are not participating in this thread. Well, I do, but I'm interested nonetheless as well, and will take part. Cheers, Georg signature.asc Description: Digital signature
Re: A problem with a watch file
Hi, On 18-10-17 15:11:00, Tommi Höynälänmaa wrote: > I have installed the key to both debian/upstream/signing-key.pgp and > debian/upstream/signing-key.asc. It still doesn't work. Run uscan with increased verbosity (-v), it might give you a hint what is going wrong. Cheers, Georg signature.asc Description: Digital signature
Re: Single Sign On for Debian
On 17-08-21 11:18:05, Enrico Zini wrote: > On Sun, Aug 20, 2017 at 04:28:05PM +, Luca Filipozzi wrote: > > > As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two > > related but orthogonal things: > > 1 collapsing user management into a single user store (LDAP)** > > I really, really like the idea of having all the accounts in a single > LDAP, regardless of the SSO system used. > > +1 to that! I second that: Using LDAP as a single source of truth. It's also possible to store SSH keys etc. in LDAP. Cheers, Georg signature.asc Description: Digital signature
