On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson
wrote:
>Marc Haber writes ("do packages depend on lexical order or
>{daily,weekly,monthly} cron jobs?"):
>> Do you people know about packages that have cron jobs that depend on
>> execution order? Would it probably be a good idea to proactively put
Package: wnpp
Severity: wishlist
Owner: Ralf Treinen
* Package name: caml-mode
Version : recent (*)
Upstream Author : Damien Doligez, Jacques Garrigue, Xavier Leroy, Didier
Remy, Ian T Zimmerman
* URL : https://github.com/ocaml/caml-mode
* License : GPL2+
Pro
As a way to avoid relying on SHA-1, would it work to have git-debpush
include a longer hash in the tag message, and tag2upload also verify
that hash?
Bastian Blank writes ("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"):
> The setting is per project, so it is available. For now I say that
> changing this globally is too disruptive.
...
> But as
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
* Package name: libnbd
Version : 0.1.9
Upstream Author : Eric Blake, Richard W.M. Jones
* URL or Web page : https://github.com/libguestfs/libnbd
* License : LGPL2+
Description : Network Block Device client library
Simon McVittie writes ("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"):
> The default of ./.gitlab.yml is problematic for Salsa *because* it's
> the upstream default, and git repositories on Salsa a
Marc Haber writes ("do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> I am wondering whether there are packages that actually do depend on
> that and how do find out short of unpacking the entire archive and
> inspecting the scripts.
My feeling is that this situation i
Jonathan McDowell writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> For the record I am in favour of this as a service. I'm not a dgit user,
> but I am a salsa user who pushes release tags there and then uploads to
> the archive. Reducing this to a single action sounds like l
Philipp Kern wrote...
> That being said: It feels like if you face this situation, you could also
> fork off a binary with a clean environment (i.e. without LD_PRELOAD) and
> minimal dependencies and only protect that with seccomp. Of course you lose
> the integration point of LD_PRELOAD that othe
Package: wnpp
Severity: wishlist
Owner: William Grzybowski
* Package name: ptvsd
Version : 4.3.0
Upstream Author : Microsoft Corportaion
* URL : https://aka.ms/ptvs
* License : EPL-2.0, MIT
Programming Lang: Python
Description : Python debugger package
❦ 19 juillet 2019 17:18 +02, Christoph Biedl :
> Upstream of the file package added seccomp support a while ago, and
> probably everyone with even a small concern about security will agree
> the file program, often being used on dubious or even doubtless
> malicious input, should use seccomp to m
On Fri, Jul 26, 2019 at 06:01:07PM +0100, Simon McVittie wrote:
> This was requested in the past in
> https://salsa.debian.org/salsa/support/issues/26, and some people
> (including me) interpreted the reply as "no, but only because upstream
> doesn't have that feature". Was that interpretation wron
Hi Ian
On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote:
> We've had a number of peripheral conversations, and informal
> internal reviews, but I think it's the stage now to have a public
> design review etc. I'm CCing this to -devel because I just did a
> lightning talk demo of the pr
* Christoph Biedl , 2019-07-27, 03:55:
The file program should[citation needed] not write to any file
...except when using the -C option.
--
Jakub Wilk
On 2019-07-27 04:55, Christoph Biedl wrote:
Eventually fakeroot-tcp, wishes to open sockets, something
I certainly would not want to whitelist.
In AppArmor case, "non-standard" use cases can be dealt with by editing
`/etc/apparmor.d/local/usr.bin.foo`, adding any necessary rules (like allowing
On 2019-07-27 03:55, Christoph Biedl wrote:
Vincas Dargis wrote...
On 2019-07-26 18:59, Christoph Biedl wrote:
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
Interesting, what are these uncommon use case
16 matches
Mail list logo
