hey,
if you don't mind please go ahead.
Thank you!
Package: sniffglue
Version: 0.11.1-5+b1
Severity: grave
I've noticed it's currently not possible to use sniffglue due to seccomp
violations:
# sniffglue -vv
Bad system call (core dumped)
#
sniffglue uses a seccomp sandbox to allow-list a reduced set of syscalls
to attempt to mitigate
hi,
the package is likely too old to have this bug, but since this package
is currently not used by anything and not meant to be used by any users,
I'd recommend to remove it from testing (we're eventually going to close
it by uploading the latest version to unstable).
cheers
On Mon, Nov 09, 2020 at 07:36:25PM +0100, Johannes Schauer wrote:
> > It is generated by our tooling. We could remove it, I don't think it is
> > indeed usefull.
>
> policy §3.4 says: "The description should describe the package (the program)
> to
> a user (system administrator) who has never me
On Sat, Oct 24, 2020 at 11:50:14AM +0800, Paul Wise wrote:
> > This is a very non-trivial downstream patch though, the project I'm
> > trying to package runs in a sandbox and loading certificates from disk
> > at runtime is not possible without redesigning some things.
>
> One option to solve this
On Sat, Oct 24, 2020 at 09:42:40AM +0800, Paul Wise wrote:
> Source: rust-webpki-roots
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team , kpcyrd
>
> Usertags: embed
>
> rust-webpki-roots is essentially a duplicate of ca-certificates.
>
>
I've tried working around this by automatically restarting the command on
crash, this has caused data-loss for me. `git annex list` showed the
file to be available in `here` only, but after running `git annex
fsck` on it git-annex noticed the local file is not available anymore
and updating the ind
Package: git-annex
Version: 7.20190129-3
Severity: important
git-annex seems to segfault after about ~30min of copying data to an s3
remote. The command I'm using is:
git annex move --to my-remote -J8 .
I found the following in my logs:
Jul 16 17:22:51 mirror kernel: git-annex:w[11659]:
Package: opensmtpd
Version: 6.6.4p1-2~bpo10+1
Severity: important
I'm using opensmtpd from backports and I'm suddenly having trouble
sending mails. I noticed that msmtp just hangs after the final `.` line
to terminate the DATA section. I've tried sending a mail manually with
`openssl s_client` but
Package: wnpp
Severity: wishlist
Owner: kpcyrd
* Package name: archlinux-repro
Version : 20200502
Upstream Author : Morten Linderud
* URL : https://github.com/archlinux/archlinux-repro
* License : MIT
Programming Lang: Bash
Description : Tools to
I'd prefer if it'd simply execute the step to rebuild with sbuild, the
version in the debian-rebuilder-setup repo[1] does that and the code
that builds on top of that expects it as well.
[1]:
https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/-/raw/master/builder/srebuild
debreb
Package: internetarchive
Version: 1.8.1-1+deb10u1
Severity: important
This is a bit of a follow up on #950289, I've retried uploading the folder and
ran out of file descriptors again, this time because the https connections
aren't closed.
The folder I'm testing with has ~10.000 files and fails mi
I'm terribly sorry, this is the correct patch:
--- >8 ---
diff --git a/internetarchive/utils.py b/internetarchive/utils.py
index db8412a..2f3e04e 100644
--- a/internetarchive/utils.py
+++ b/internetarchive/utils.py
@@ -235,14 +235,16 @@ def recursive_file_count(files, item=None,
checksum=False):
Package: internetarchive
Version: 1.8.1-1
Severity: important
I've tried to upload to archive.org and noticed ia crashes on
large folders.
$ ulimit -n
1024
$ ia upload asdf ./folder-with-more-than-1024-files/
[...]
OSError: [Errno 24] Too many open files
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
The rust-pcap package is no longer in use and seems unmaintained
upstream. There are no reverse dependencies.
Thank you very much!
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
The rust-crossbeam-epoch-0.5 package is no longer in use. There are no
reverse dependencies.
Thank you very much!
On Wed, Oct 30, 2019 at 06:11:47PM -0700, Sean Whitton wrote:
> There are some inaccuracies in d/copyright. I'm filing this bug at RC
> severity because the MIT license requires all copyright claims to be
> collated in d/copyright.
>
> (The package is dual-licensed under Apache-2.0, which the FTP
On Thu, Oct 17, 2019 at 09:40:59PM +0200, Raphael Hertzog wrote:
> Look, I'm not a cargo/rust expert, I won't design the tool for you but I
> implemented dpkg-gensymbols and the symbols support for dpkg-shlibdeps
> and I'm pretty confident that such a solution can work for your case too.
>
> We ar
On Thu, Sep 26, 2019 at 04:57:10PM +0100, peter green wrote:
> apt-get build-dep rust-sha-1
> apt-get source rust-sha1-1
This one should be rust-sha-1
> dpkg-buildpackage -B
> dcmd --deb dpkg -i rust-sha-1_0.8.1-2_amd64.changes
>
> > Selecting previously unselected package librust-sha-1+asm-dev
On Sun, Sep 22, 2019 at 11:07:57PM +0100, peter green wrote:
> Package: rust-sha-1
> Version: 0.8.1-2
> Severity: serious
>
> If rust-sha-1 is re-built, the version mentioned in virtual package names in
> the provides changes from "0.4" to "0.8", but the version mentioned in the
> virtual packag
d":wot_stats.getUserId(),
"sess":wot_stats.getSession()['id'],
"q":encodeURIComponent(url), //(kpcyrd): this is the current url
"prev":encodeURIComponent(wot_stats.last_prev), //(kpcyrd): this is
the previously see
Package: mongodb-server
Version: 2.4.10-5
Severity: grave
Tags: security
There's a bugfix[1] from 2013 for an issue that wasn't announced for
security that's currently not included in debian stable.
[1]: https://jira.mongodb.org/browse/SERVER-9476
Current mongodb in stable logs authentication at
On Sat, Jul 30, 2016 at 05:53:10AM +, László Böszörményi (GCS) wrote:
> While this is a real issue, I somewhat agree with upstream. Being a
> system administrator for long time, I know as others should know:
> - don't run sensitive services on a machine which can be accessed by
> untrusted user
So, upstream just closed the issue I created with 'Works as Designed'
blaming the default umask for the bug and that specifying file
permissions for files created by mongodb is not something mongodb should
do.
https://jira.mongodb.org/browse/SERVER-25335#comment-1342085
The bug is locked, what do
Package: mongodb-clients
Version: 2.4.10-5
Severity: grave
Tags: security
During the report on redis-tools
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832460), lamby@
linked to a codesearch and the same bug was found in mongodb-clients.
mongodb-clients stores its history in ~/.dbshell, thi
> > Another bug report by @denisvm, this time on the linenoise library:
> > https://github.com/antirez/linenoise/issues/121
>
> Indeed this looks like it might affect some other packages in Debian:
>
> https://codesearch.debian.net/search?q=int+linenoiseHistorySave&perpkg=1
>
> Can you check th
> > I've contacted upstream on 2016-05-30 without any reaction at all and
> > discovered this bug was first reported 3 years ago, still unfixed.
> > @RedisLabs keeps referring to their paid support on twitter.
>
> Boo. Is there an upstream bug# for this or was this reported privately?
My report:
Package: redis-tools
Version: 2.8.17-1+deb8u3
Severity: grave
Tags: security
redis-cli stores its history in ~/.rediscli_history, this file is
created with permissions 0644. Home folders are world readable as well
in debian, so any user can access other users redis history, including
AUTH commands
28 matches
Mail list logo
