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 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.
>
>
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
17 matches
Mail list logo
