Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

[Paul Wise]

On Sat, 2023-07-22 at 17:45 +0200, Hannes von Haugwitz wrote:

> What about to add a warning to apt if *-security or *-updates is
> configured in the sources list and `APT::Default-Release` is set but
> does not match the security or updates repo?

That seems like the right solution here, please file a bug on apt.

Please also check these packages and file bugs against any broken ones:

https://codesearch.debian.net/search?literal=1=APT%3A%3ADefault-Release

Some of these are probably best filed upstream instead of in Debian,
especially for issues in files not used by Debian like Dockerfiles.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

[Paul Wise]

On Fri, 2023-07-21 at 11:04 +0200, Daniel Gröber wrote:

> Do you have any references on how this decision came to be?

I think it was about making the suite naming more intuitive, consistent
with other suites and possibly also some dak implementation concerns.

> One mention I found is in Raphaël and Roland's DAH (now in CC):
> https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade

Probably better to file a bug about this, so it is tracked.

> The places I'm most concerned about, people's brains and random web sites,
> aren't so easily fixed unfortunately. Advice to set this is splattered all
> over the web, I really don't understand why we made a change so seemingly
> ill advised as this?
> 
> A web search for "Debian Default-Release security" didn't reveal anything
> talking about this problem, especially not our release notes, so I think
> this change didn't get the publicity it deserves at the very least.
> 
> What I don't understand is why the security repo codename wasn't changed to
> $codename/security? Wouldn't that be handled correctly by APT? Unless the
> /update string in particular had special handling?

You will have to ask the apt developers and archive admins about this,
but at the end of the day reverting it is unlikely to happen, so
probably it is something everyone will just have to learn to live with.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

[Paul Wise]

On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:

> It seems packages from the debian-security repository are not affected by
> this increased priority and will not get intalled as a result.

This was documented in the release notes for Debian bullseye:

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

I have updated a few wiki pages that mention APT::Default-Release too.

https://wiki.debian.org/DebianUnstable?action=diff=144=145
https://wiki.debian.org/DebianEdu/Status/Bullseye?action=diff=107=108
https://wiki.debian.org/Wajig?action=diff=20=21
https://wiki.debian.org/FunambolInstallation?action=diff=9=10

If there is other documentation of APT::Default-Release that should get
updated, please let us know so that we can fix it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

bookworm nearly ready

[Paul Gevers]

Dear readers,

The bookworm release is in it's final stages. Please expect the release 
to happen in several hours from now which means that updates of systems 
will see new metadata, e.g. switching bullseye from stable to oldstable.


On behalve of the Release Team.
Paul


OpenPGP_signature
Description: OpenPGP digital signature

should the Release Notes be updated concerning bookworm security

[Paul Gevers]

Dear security team,

I know it's a bit late, but are you aware of issues that are worth 
mentioning in the release notes from your point of view?


We have updated the text about golang and rustc in this cycle, chromium 
got a mention about reduce support time wise and I updated the openjdk 
versions and dates. Is that all?


Paul

Current version jumping straight to the security section:
https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html#limited-security-support
or the source:
https://salsa.debian.org/ddp-team/release-notes/


OpenPGP_signature
Description: OpenPGP digital signature

Re: Should singularity-container make it to next release?

[Paul Gevers]

Hi Nilesh,

On 26-01-2023 10:06, Nilesh Patra wrote:

I guess something that changed since then is that upstream is aware
about it and can help a bit with backporting. However the onus to
maintain it in stable is still on the maintainer and security@ (to some
extent)
It is bit of a high-effort maintainance (in stable) as far as I can see.


I may (or may not) be misunderstanding you. As a maintainer, it's up to 
you to commit to the effort. If you're up to it and judge it's feasible, 
I'm not going to block you on that. I understood you raised a concern 
about it being feasible, that's why we ended up here. If you commit 
(obviously best effort, but we'll expect you to spend time on it) *and* 
the security team agrees that with your commitment it's supportable, 
I'll remove my concern. Our concern is that we *don't* want new versions 
in stable to fix security issues if those new versions are not 
bugfix-only releases. We have to accept that for browsers, because 
shipping without them seems like a disservice to nearly all of our 
users, but still it's something we really don't like.



fasttrack still has much less visibility / availability than
an official stable release, or even backports.


Obviously that will only be solved if it's more used (and/or if 
eventually it can be moved to the debian.org namespace.) But indeed.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Should singularity-container make it to next release?

[Paul Gevers]

Hi,

On 25-01-2023 20:14, Moritz Muehlenhoff wrote:

On Sat, Jan 21, 2023 at 08:34:40PM +0100, Salvatore Bonaccorso wrote:

So in my understanding of the above the situation around singularity-container,
which lead for buster to https://bugs.debian.org/917867 and keeping it out of
the stable release, did not really change in the aspect of beeing able to patch
vulnerabilities to the stable branch once upstream versions moved on, is this
correct interpretation? In context from #917867, it was even in stretch at
first, but needed to be removed after stretch was released in a point release.

If this is correct, then we probably should not include singularity-container
in bookworm, better than possibly need to remove it after bookworm release in a
point release.


Agreed.

Cheers,
 Moritz


I have forwarded this message as bug #1029669. Unless we get more 
confidence that it's supportable, let's keep it out of stable. I guess 
fasttrack [1] is currently the best forum to supply 
singularity-container to our users.


Paul

[1] https://fasttrack.debian.net/


OpenPGP_signature
Description: OpenPGP digital signature

Re: Vulnerability in pcs or is it in more generic code?

[Paul Wise]

On Fri, 2022-09-09 at 22:41 +0200, Ola Lundqvist wrote:

> I see that I was not clear what I meant with "in general" :-)

Woops, sorry for the noise :)

> Here I found how the generic source code looks like:
> https://rubydoc.info/gems/thin/1.3.1/Thin%2FBackends%2FUnixServer:connect
> 
> You can see the umask(0) there.
> 
> That is what I think is insecure, not pcs itself.

Agreed.

> But I think Thin::Backends::UnixServer#connect is still insecure.

It looks like the issue was introduced in this pull request:

   https://github.com/macournoyer/thin/pull/28

It sounds like unicorn might have the same issue as thin.

Looking at the unicorn code, it sets the default umask to 0
when the umask option is not set, so not quite as bad but still.

The justification for the default umask of 0 in unicorn is:

   #   Typically UNIX domain sockets are created with more liberal
   #   file permissions than the rest of the application.  By default,
   #   we create UNIX domain sockets to be readable and writable by
   #   all local users to give them the same accessibility as
   #   locally-bound TCP listeners.

So the choice of umask 0 is deliberate in unicorn and the thin folks
copied that choice and dropped the possibility of overriding it,
since they did't have an options argument for the function.

Since UNIX domain sockets are often used for situations that are not
like localhost TCP sockets, that was probably the wrong choice, but
the unicorn/thin folks are likely from the web developer community,
which is mostly focused on HTTP and TCP and often use localhost for
development, so it was the right choice within their bubble.

I feel like the APIs of both thin and unicorn need redesigning so that
the choice of umask to use must be made by the caller. Then the web
developer community can use 0 and others will choose a safe value.

Really the web developer community shouldn't use 0 either but I expect
that convincing them of that might not be possible.

I'm not sure how palatable the API change will be to thin/unicorn.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Vulnerability in pcs or is it in more generic code?

[Paul Wise]

On Mon, 2022-09-05 at 21:38 +0200, Ola Lundqvist wrote:

> I agree that it is good to fix the pcs package, but shouldn't we fix
> the default umask in general?
> I would argue that the default umask is insecure.

bookworm login sets new user home directories to secure permissions:

   $ grep -E 'HOME_MODE\s*[0-9]' /etc/login.defs 
   #HOME_MODE   0700

This somewhat mitigates, but not completely, the umask being insecure:

   $ grep -E 'UMASK\s*[0-9]' /etc/login.defs 
   UMASK022

I can't find any bugs open about changing the default umask,
but it was mentioned in replies to the recent adduser thread:

https://lists.debian.org/msgid-search/yiejaly0ny0+0...@torres.zugschlus.de

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Concerns about Security of packages in Debain OS and the Operating system itself.

[Paul Wise]

On Tue, 2022-05-24 at 16:27 +0100, piorunz wrote:

> Important note: Disabling bullseye-updates is actually causing
> point-release updates to be delivered on one, predetermined date,
> bundled all together. By disabling this entry you still get them all,
> but in controlled fashion, you are not "beta tester" of these packages.

This is not exactly correct. The bullseye-updates suite should be used
by almost all users. The only suite where you are really a beta tester
for the next point release is bullseye-proposed-updates. The other two
suites recieve only very important updates:

bullseye: read-only except during point releases

bullseye-security: receives security updates regularly

bullseye-updates: receives occasional time-sensitive and important
updates, such as updates to the timezone database, which often happen
just days before the timezone changes, or fixes for packages that get
completely broken by some external services on the Internet, or fixes
for packages that were initially broken but that wasn't found. There
are only three updates in it currently, two of them are updates to the
timezone database and one is clamav, which sometimes needs updates so
it can continue to pull in antivirus detections.

https://deb.debian.org/debian/dists/bullseye-updates/main/source/Sources.xz

bullseye-proposed-updates: the contents of the next point release;
some changes come from bullseye-security, some from bullseye-updates
and some from package maintainers.

https://release.debian.org/proposed-updates/stable.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

[Paul Wise]

On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote:

> And if it is indeed possible, how can I switch from i386 to 
> amd64?  Can this be done with the apt tools?  Then during the 
> migrating some packages will be from amd64 already while others 
> will be still i386.  How does that go right?

If your hardware supports it, you can either reinstall from scratch or
cross-grade an existing install from i386 to amd64, either using the
crossgrader tool or more manual methods of doing the same thing.

https://packages.debian.org/crossgrader
https://wiki.debian.org/CrossGrading

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Compiled list

[Paul Tagliamonte]

STIGs are maintained by DISA, not by Debian

  Paul

On Wed, Mar 2, 2022 at 9:42 AM Stephanie Hall  wrote:

> Good morning,
>
> Do you have an excel version of a STIG for Debian 9 & 10 that you would be
> willing to share?
>
> Thank you in advance!
>
> --
>
> Stephanie Hall
>
> Oteemo, Inc. <https://oteemo.com/>
>
> Sr. Consultant, Cybersecurity
>
> m: (315)-723-9951
>
> e: sh...@oteemo.com
>
>
> <https://www.linkedin.com/in/stephaniewilliamsatignitemktg/>
> <https://twitter.com/ignitemarketing>
>
> Oteemo Customer Love <https://oteemo.com/what-our-clients-say/>
>
>
>


-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

Re: A message from Zoom Video Communications, Inc. -- re: free / open source software licensing, security

[Paul Wise]

On Fri, 2022-01-28 at 20:23 +, Zoom Video Communications wrote:

> if a critical CVE is discovered at some point after we release, it’s
> best not to publish which specific Zoom client version contains the
> vulnerability, as that essentially gives a roadmap to exploitation
> for hackers.

This is misguided at best, hackers are able to compare binaries and
find out what changed. Some adversaries have this automated and there
is even work on automatically deriving exploits from those diffs.

> https://explore.zoom.us/en/opensource/source/
> "We provide our OSS attribution in this manner intentionally, which
> is to say, it’s legally permissible (as per OSS licensing
> requirements)

On Fri, 2022-01-28 at 20:23 +, nmschu...@desmas.net wrote:

> - Is the stated legal assertion accurate?

It completely depends on what components they are using and what
licenses they are using those components under. If you suspect a
violation of one of those licenses, please verify the details and
contact the copyright holder for the components in question.

> - Does an open-ended request suffice

Given their response, I expect that they will reject such a request.

> - Must references be made (more) concretely, and if so ... how?

Looking at the referenced web page, I see components licensed under the
LGPL, which means that each time Zoom releases software containing
those components, they must also release the exact corresponding source
for the version used by their software, as well as complying with the
relinking and other requirements of the LGPL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1001451: Candidate script updates

[Paul Wise]

On Tue, 2022-01-11 at 11:20 +, Neil Williams wrote:

> I might need to brush up on my Perl and make a patch for lintian which
> downloads the sec tracker JSON and checks the CVE list in the .changes
> file - warnings from lintian are more likely to get fixed prior to
> upload. Depends if you think this happens sufficiently often that it is
> a problem worth solving. (Considering how long it's been since I did
> that amount of code in Perl, maybe I'm better filing the bug against
> lintian and seeing if someone else can come up with a patch... - again,
> only if it happens sufficiently often.)

FTR, lintian does not do any network requests, so this approach won't
be accepted. The best option you can get is a script to do the download
at the lintian release time. Unfortunately this means the data will get
outdated quickly and make the check less useful.

This check could be added to devscripts, debsecan or duck.

The sectracker JSON is very large, so I think that a new API will be
needed for any tool that implements such a check.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: replacing misleading debian.org/security claims

[Paul Wise]

On Thu, 2021-12-30 at 11:04 -0500, Silas Cutler wrote:

> I'd also like to see information on both how to submit
> vulnerabilities as well as how to contribute to getting them fixed.

These are addressed in the FAQ:

https://www.debian.org/security/faq#discover
https://www.debian.org/security/faq#help
https://www.debian.org/security/faq#care

They refer to the developers reference and security tracker docs:

https://www.debian.org/doc/developers-reference/pkgs.html#bug-security
https://security-tracker.debian.org/tracker/data/report

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: replacing misleading debian.org/security claims

[Paul Wise]

On Tue, 2021-12-28 at 19:46 +0100, max wrote:

> Debian's security updates are created by volunteers working in their
> spare time. Some packages may receive more attention than others. To
> view the current list of known unfixed vulnerabilities see
> https://security-tracker.debian.org/tracker/status/release/stable

This isn't entirely factual either. The LTS team is mostly composed of
people being paid to contribute, with some volunteers. Some of the
stable security team may also be paid, but there isn't any public
information about who is paid and who they work for.

https://wiki.debian.org/LTS/Team
https://wiki.debian.org/LTS/Funding

I suggest contacting the stable and LTS security teams to draft a
statement that best represents the current and future reality of Debian
security updates.

https://www.debian.org/security/faq#contact
https://wiki.debian.org/LTS#Get_in_contact
https://wiki.debian.org/LTS/Contact

> (Side note: It seems that NVD tends to assign "medium" severity to
> vulnerabilities initially, but upgrades them to "high" or "critical"
> later. However, Debian keeps showing the initial severity rating)

Please send a patch, issue or mail about that separately.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1001191: security-tracker: include more information in page titles

[Paul Wise]

Package: security-tracker
Severity: wishlist

It would be nice to include some more information in page titles, so
that records of those page titles in search engine results, browser
tabs and browser history are more useful to visitors to the site.

Here are examples of the potential changes that could be made:

URL: https://security-tracker.debian.org/tracker/source-package/samba
Current: Information on source package samba
Potential: Security info for Debian samba source package: 26 open issues, 3 
open unimportant issues, 132 resolved issues, 62 security announcements

URL: https://security-tracker.debian.org/tracker/CVE-2021-20254
Current: CVE-2021-20254
Potential: CVE-2021-20254 - samba - #987811 - unfixed in buster - A flaw was 
found in samba. The samba smbd file server [...]

URL: https://security-tracker.debian.org/tracker/DSA-5015-1
Current: DSA-5015-1
Potential: DSA-5015-1 - samba - security update - CVE-2020-25717 fixed in 
buster (security) version 2:4.9.5+dfsg-5+deb10u2

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: sources.list 4 bullseye-security

[Paul Wise]

On Sat, Jul 3, 2021 at 9:31 PM Salvatore Bonaccorso wrote:

> I have pushed
> https://salsa.debian.org/webmaster-team/webwml/-/commit/4ca2253325130f7e96bf2644d31cf5a95fdf7bcc

Note that updating translations at the same time as the English page
causes more work for the translation teams, who have to bump the
translation check header. If you first commit the English change and
then commit the translation changes, you can use ./smart_change.pl
(see --help for instructions) to bump the translation check headers in
the second commit.

> Once bullseye will be released the example sources.list entry in
> https://www.debian.org/security/#keeping-secure will need to be
> adapted as well to match bullseye's sources.list entry for the
> security archive.

I've made a commit that means this will be automatically updated at
release time:

https://salsa.debian.org/webmaster-team/webwml/-/commit/06a365347b5545c26d162ef4887514d171f5dcd0

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Is this the right place to discuss no-dsa choices?

[Paul Wise]

On Tue, May 11, 2021 at 11:12 PM Andrew Bartlett wrote:

> I'm keen to discuss the thought process behind a number of the no-dsa
> flags on Samba security releases.  Does this list reach those involved
> in that, or is this more a general 'interest in security' list?

It tends to be more of a general security list. Probably contacting
the security team directly on secur...@debian.org or
t...@security.debian.org is more appropriate, or if you want to
discuss the issues in public, the debian-security-tracker list.

https://security-tracker.debian.org/tracker/data/report
https://lists.debian.org/debian-security-tracker/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Guest Post Request for lists.debian.org

[Paul Wise]

On Tue, Mar 16, 2021 at 4:42 AM Gunnar Wolf wrote:

> Thank you for your offer. The Debian project is not interested in this
> kind of collaboration.

That was clearly a spammer, best get listmasters to ban them rather
than responding.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Misuse/Abuse

[Paul Wise]

On Tue, Oct 13, 2020 at 7:14 AM Knieling, Christian (IANM) wrote:

> I don't know if this messages reaches the right persons, but someone may
> forward it. You may at least remove the files which are accessible on
> paste.debian.net.

I forwarded this to the paste.d.n admin and they removed them.

For future reference, the admin contact is listed on the left side of the site:

https://paste.debian.net/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Scripts that run insecurely-downloaded code

[Paul Wise]

On Fri, May 1, 2020 at 7:12 PM Rebecca N. Palmer wrote:

> Around 200 packages [0] include upstream scripts that download code via
> (non-secure) http, then run it without an integrity check.

A lot of these appear to be in documentation, dependency installation
scripts (such as in docker) or continuous integration scripts.

> How should this be dealt with?

Review each one manually. Report security issues for things that end
up in a .deb to upstream security contacts along with CVEs for each
issue that warrants the fixes. The upstream security reports should
probably get a Debian report too, as many upstreams will be
un(der)maintained. For CI, Dockerfiles, documentation issues probably
just an upstream pull request.

> - (imperfect) Lintian check based on [0]?

Probably better added to per-language static analysis tools like
ShellCheck etc. I don't think lintian is the place to do static
analysis, that should be done by upstream developers either on their
dev machines or in their CI and possibly by distro packagers when
analysing new upstream releases. check-all-the-things aims to make it
easy and useful for devs/packagers to run all the available tools.

https://github.com/collab-qa/check-all-the-things/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Scripts that run insecurely-downloaded code

[Paul Wise]

On Fri, May 1, 2020 at 8:18 PM Rebecca N. Palmer wrote:

> This is already policy (and enforced by blocking network access) for
> official Debian package builds: dependencies must be installed by the
> package manager, not the build script.

Correction: the debian.org buildds do not at this time block any
network access. The main issue is that schroot does not support it and
it has been orphaned and unmaintained for years. You might be thinking
of pbuilder, which does do this by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: debcheckroot v2.0 released

[Paul Wise]

On Wed, Apr 1, 2020 at 6:01 PM vi...@vheuser.com wrote:

> Did the discussion of continuing support for DANE end??

In case I mislead anyone, a clarification:

Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.

Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: debcheckroot v2.0 released

[Paul Wise]

On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote:

> I hope this is gonna happen anytime soon. DANE and thus a valid TLSA 
> record is of very high value and importance for getting a genuine 
> download of Debian. As I have mentioned before downloads via Tor can be 
> spoofed like my last Debian Live 10 download which turned out to be 
> infected by debchecheckrooting against the Debian 10 DL-BD.

TBH, very few people care about DNSSEC and vastly fewer than that care
about DANE so I expect at some point support for both will disappear
from both the DNS root servers and all DNS software.

You shouldn't be relying on DNSSEC/DANE/TLS to verify Debian image
downloads anyway, since they have OpenPGP signatures:

https://www.debian.org/CD/faq/#verify
https://www.debian.org/CD/verify

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: debcheckroot v2.0 released

[Paul Wise]

On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote:

> I've forwarded this to the Debian sysadmins IRC channel. I think it is
> related to the fact that the cdimage.d.o server is not managed by the
> Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to
> get certs, and then of course the TLSA records got outdated after the
> renewal. For other debian.org domains that are not managed by the
> Debian sysadmins, we centrally create the certs and propagate them to
> external services (like the CDNs for deb.d.o). The cdimage.d.o server
> isn't a CDN and probably doesn't have cert APIs but we can probably
> use the same approach to fix this.

The result was that the mismatch was caused by a bug in the Debian
sysadmin puppet. The fix was to remove the TLSA records for this
domain due to the aforementioned management disconnect. If the cert
management for cdimage.d.o changes to the deb.d.o setup then the TLSA
records will return and be correct.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: debcheckroot v2.0 released

[Paul Wise]

On Mon, Mar 23, 2020 at 4:00 PM Elmar Stellnberger wrote:

> The only site which is still making problems is cdimage.debian.org.
> Could any good Christ from the Debian community have a look at this
> issue. The server maintainers would need to complain about the rogue cert!

I've forwarded this to the Debian sysadmins IRC channel. I think it is
related to the fact that the cdimage.d.o server is not managed by the
Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to
get certs, and then of course the TLSA records got outdated after the
renewal. For other debian.org domains that are not managed by the
Debian sysadmins, we centrally create the certs and propagate them to
external services (like the CDNs for deb.d.o). The cdimage.d.o server
isn't a CDN and probably doesn't have cert APIs but we can probably
use the same approach to fix this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: package for security advice

[Paul Wise]

On Sat, Mar 7, 2020 at 9:30 AM Russell Coker wrote:

> I think it would be good to have a package for improving system security.
...
> What do you think about this idea?

There are a number of other tools for this sort of thing already,
usually they get written and become outdated at some point then
someone writes a new one and so on and so on. An example of a tool I
sponsored in the past is lynis.

ISTR seeing some tools for checking Debian deployments in
high-security environments on GitHub somewhere, but I don't recall the
repo.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#949260: security-tracker: add cvedetails.com to Source?

[Paul Wise]

On Sun, Jan 19, 2020 at 3:05 AM Dmitry Smirnov wrote:

> It might be nice to add "cvedetails.com" to CVE Source links.
>   https://www.cvedetails.com/cve/CVE-2019-13072/

This doesn't appear to add any details that aren't on Mitre:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13072

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Why no security support for binutils? What to do about it?

[Paul Wise]

On Wed, 2020-01-01 at 10:29 +0100, Elmar Stellnberger wrote:

>Up to now I did not see any notable effort to support malware reverse 
> engineering under Linux. The only program I knew was boomerang for 
> decompiling malware but it seems to be unsupported since long. I would 
> really be in need of such software since I have plenty of images of 
> rootkitted installations and tampered BIOS images (f.i. one does not 
> boot via USB and does not allow BIOS updates; you can not get rid of it 
> unless you flash the BIOS chip of you mainboard externally).

There are lots of such tools, examples:

peframe
Radare/Cutter
radare-uefi (not in Debian)
Ghidra (not in Debian)
RetDec (not in Debian)

If you want to package the missing ones, check out this:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Why no security support for binutils? What to do about it?

[Paul Wise]

On Wed, Jan 1, 2020 at 1:00 PM Florian Weimer wrote:

> Doesn't lintian on ftp-master use disposable VMs?

No mention of qemu/kvm in dak.git nor any qemu processes running on
ftp-master.d.o, so I don't think so.

> Some of its checks look inherently dangerous, e.g. the bash -n check for 
> shell syntax.

What is dangerous about `bash -n`? IIRC that is supposed to not
execute shell code, but I guess you mean that the shell parsers in
Debian (bash/dash/etc) are particularly fragile? The same can probably
be said for the manual page checks and probably other parts of
lintian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Why no security support for binutils? What to do about it?

[Paul Wise]

On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote:

> BFD and binutils have not been designed to process untrusted data.
> Usually, this does not matter at all.  For example, no security
> boundary is crossed when linking object files that have been just been
> compiled.

There are definitely situations where vulnerabilities in binutils
(mostly objdump) are important and a security boundary could be
crossed, for example; running lintian on ftp-master, malware reverse
engineering and inspection of binaries for hardening features.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mitigating malicious packages in gnu/linux

[Paul Wise]

On Tue, Nov 19, 2019 at 7:30 PM Georgi Guninski wrote:

> * What do linux vendors to avoid malicious packages?

Some folks do audits of changes to upstream code, some folks run
static analysis tools on upstream code.

> * As end user what can I do to mitigate malicious packages?

Compartmentalise your computing, either with multiple computers or
using something like Qubes:

https://www.qubes-os.org/

> 1. This already happened in 2003 with the micq package in debian:  unnoticed
> easter egg causing DOS, see [1].

Detecting this requires inspection of code changes. It isn't clear how
many people inspect changes in the software they use or maintain
packages of.

> 2. This already happened to Redhat in 2008? see [5], Red Hat OpenSSH Backdoor
> Vulnerability

Sounds like it would be blocked by a proper Reproducible Builds setup:

https://reproducible-builds.org/

> 3. In 2015 Microsoft issued weird update, see [6],[7].

Weird indeed.

> 4. Portable malware in portable languages (Java, Javascript), taking the
> worst from windoze.

Not sure what you refer to here.

> 5. Google play. Google play has about 2.8M packages [2] for android. Debian
> has about 31K packages [3] XXXold_stat. To our surprise google play is only
> about 90 times bigger than debian per number of packages and the metrics
> is unclear for size of binary packages or lines of code. Google scans for
> malware, not sure how effective is this.Google's permissions of applications
> are mitigating factor.

We often hear stories about how Google Play is full of applications
that spy on you. There hasn't been much research on that in Debian,
but there are definitely privacy issues in Free Software too, some
examples for Debian are listed here:

https://wiki.debian.org/PrivacyIssues

> 6. The art of backdooring: sufficiently sophisticated backdoor is
> indistinguishable from secure code, see Obfuscation contest [4].

Anyone who sees code from the IOCCC or similar code in the real world
will be immediately suspicious of it since it is obviously obfuscated.

Code from the Underhanded Contests is far more concerning since it
aims to look like real code but be subtly buggy:

http://underhanded-c.org/
https://underhandedcrypto.com/
https://u.solidity.cc/
https://underhanded.rs/

> 7. Getting root vs reading $HOME vs euid == DAEMON. Getting root is important,
> but there is more interesting in user's $HOME.

Things like multiple devices, Qubes, Flatpak and other
containerisation tools can help here, but all code has had bugs in the
past that can help crossing those boundaries, including network
firmware, network drivers, virtual machines, kernels, container tools
etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Open Source

[Paul Wise]

On Mon, Nov 4, 2019 at 7:57 AM Lindsey Lassen wrote:

> Hello, I am unsure if I am contacting the correct department for my concern. 
> I have had your open source software added on my cell phone and I have never 
> authorized your company nor anyone else for that matter. It would be a great 
> resolve and weight off my shoulders, if you could direct me in the right 
> direction to get some answers in regards to locating who is responsible for 
> this occurring, as well as, how I might be able to remove and eliminate this 
> from happening in the future.

Could you describe the software in question or provide a screenshot of
the software? It is unlikely that anyone from Debian had any contact
with your cell phone. It is unlikely that any software from Debian is
able to be installed on any cell phones.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: I forgot my password and Debian need password when booting

[Paul Tagliamonte]

On Sun, Oct 27, 2019 at 05:05:44PM -0400, Craig wrote:
>Can you get grub to appear? If you can an easy way to get in
> 
>Go to the end of the line with options and add to the end I think
>shell=/bin/sh

`init=/bin/sh` is what you're thinking of, but it won't work here,
since the drive is encrypted.

Cheers,
  paultag


signature.asc
Description: PGP signature

Re: I forgot my password and Debian need password when booting

[Paul Wise]

On Sun, 2019-10-27 at 10:24 +0330, Mostaf Faridi wrote:

> After type password several times. Busybox boot.
> Can busybox solve this problem?

That sounds like an initramfs shell, which isn't helpful here.
You will need to boot a Debian live image, install bruteforce-luks and
then try to crack the password.

https://www.debian.org/CD/live/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: I forgot my password and Debian need password when booting

[Paul Wise]

On Sat, Oct 26, 2019 at 8:51 PM Mostaf Faridi wrote:

> I installed Debian on HDD with encryption two years ago and when Debian want 
> boot need password.
> I forgot that password.
> Do I have chance for recover my Data?

If you remember some part of your password it might be possible to use
the bruteforce-luks package to recover the full password, if that
fails then you will need to reinstall and restore data from any
backups you might have.

https://packages.debian.org/stable/bruteforce-luks
https://github.com/glv2/bruteforce-luks

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: request for changing SUSE reference URL

[Paul Wise]

On Tue, Sep 17, 2019 at 11:48 PM Alexandros Toptsoglou wrote:

> Could you please change this and from now on point to SUSE bugs using
> bugzilla.suse.com which is the correct and basically the one that we
> always reference?

I've made a commit changing all bugzilla.novell.com references to
bugzilla.suse.com.

https://salsa.debian.org/security-tracker-team/security-tracker/commit/b37757a5658d6f141d207fea480539abf366924e

The links on every CVE page supplied by the first hunk will require
the Debian security team to update the live deployment of the security
tracker, the Notes sections of individual CVE pages will get updated
automatically.

To avoid more references to bugzilla.novell.com appearing, I think it
would help if you could get all bugzilla.novell.com URLs to redirect
to their equivalent bugzilla.suse.com URL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Paul Gevers]

Hi

On 29-08-2019 14:28, Raphael Hertzog wrote:
> (Note: pkg-security@tracker.d.o is not a valid email, dropped)
> 
> Hi,
> 
> On Thu, 29 Aug 2019, Holger Levsen wrote:
>>> In general, we (Debian) don't have a good answer to this problem and
>>> virtualbox is clearly a bad precedent. We really need to find a solution
>>> to this in concertation with the release managers.
>>
>> so I've added them to this thread.
>>
>> youtube-dl is in the same boat...

Wasn't Pirate already working on a solution? How is that faring? I know
it doesn't have all the properties you are seeking, but ...

> To kickstart the discussion, I can try to make a proposal.
> 
> 1/ We tag such packages in some way (let's say a new field
>   "Backport-Only: yes")
> 
> 2/ Those packages are considered like others for testing migration
>but when britney accepts them, instead of adding them to 
> ""
>it adds them to "-backports". Obviously this requires
>britney to consider the combination of both repositories when
>considering migrations. And it will require changes to generate two
>separate output files for dak.
> 
>The hardest part is ensuring that testing doesn't contain packages that
>would depend on packages present only in the backports part. Not sure
>we want to handle this directly within britney. It might be better to
>have QA tools for this and report bugs as appropriate.
> 
> The good thing is that those applications are then available from day 1 in
> stable-backports after the release.
> 
> The backports rules would have to be tweaked a bit to accept backports
> coming out of "-backports". But all those aspects are a
> relatively minor detail IMO.

in the discussion that Pirate had with the backports masters, it was my
interpretation that they didn't like it.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Have I caught a firmware attack in the act? Or am I just paranoid?

[Paul Wise]

On Tue, Aug 13, 2019 at 3:30 PM Rebecca N. Palmer wrote:

> but at least some USB flash drives instead use an SCSI command [1],
> which usbguard won't catch.

This seems like a significant missing feature, but I guess it would
require a fair bit of Linux kernel work to support filtering such
commands.

> I'm also not sure whether firmware-based malware is common enough to be
> something the average developer should worry about.

IMO proprietary software is worrisome in any context and the Linux
kernel definitely needs hardening against malicious devices. There has
been some recent work on exploiting radio firmware and then exploiting
Linux from there, here are two examples that come to mind:

https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
https://blade.tencent.com/en/advisories/qualpwn/

> Aug  5 07:21:51 rnpalmer-laptop kernel: [34901.758084] usb 3-2.1:
> SerialNumber: F32402A6

This got deleted.

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579113] usb 3-2.1: New
> USB device found, idVendor=058f, idProduct=1234

This vendor/product combo is known to usb.ids:

/usr/share/misc/usb.ids:058f  Alcor Micro Corp.
/usr/share/misc/usb.ids:1234  Flash Drive
...
/usr/share/misc/usb.ids:6387  Flash Drive
...
/usr/share/misc/usb.ids:9380  Flash Drive
/usr/share/misc/usb.ids:9381  Flash Drive
/usr/share/misc/usb.ids:9382  Acer/Sweex Flash drive

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579117] usb 3-2.1: New
> USB device strings: Mfr=1, Product=2, SerialNumber=0

The serial number went to zero.

> Aug  6 21:52:26 rnpalmer-laptop kernel: [50370.579121] usb 3-2.1:
> Manufacturer: Alcor Micro

This changed from "Generic" and idVendor=058f is Alcor Micro.

Based on the serial number deletion, I'd speculate that some internal
part of the flash holding details about the device identity
malfunctioned, so the firmware reverted back to the default hardcoded
product id for Alcor flash drives. No idea if this is a reasonable
theory or what caused the malfunction, malware or otherwise.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Reg: secure boot in debian 9 stretch

[Paul Wise]

On Wed, Mar 13, 2019 at 11:00 AM Paul Wise wrote:

> Debian 10 buster will ship with secure boot support and I seem to
> remember that there are plans to backport that to Debian 9 stretch.

PS: if you would like to test this, details are here:

https://wiki.debian.org/SecureBoot/Testing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Reg: secure boot in debian 9 stretch

[Paul Wise]

On Wed, Mar 13, 2019 at 7:00 AM Matthew Crews wrote:
> On 3/12/19 5:37 AM, Srinivas Rao wrote:
> > could you please tell me , secure boot is available in Debian 9 stretch
> > or not ?
>
> It is not.

Debian 10 buster will ship with secure boot support and I seem to
remember that there are plans to backport that to Debian 9 stretch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Should easter eggs be disabled in Debian's php packages?

[Paul Wise]

On Fri, Jan 18, 2019 at 1:55 PM Reed Black wrote:

> To answer my own question, after PHP 5.5 the easter egg was removed already.

So the issue would only be present in wheezy. I guess the ELTS folks
might like to disable them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Should easter eggs be disabled in Debian's php packages?

[Paul Wise]

On Fri, Jan 18, 2019 at 2:00 AM Reed Black wrote:

> PHP includes an easter egg. On any PHP page, one can add any of these after 
> the .php part of the path in order to display special results:

I can't seem to reproduce this with Debian's PHP pages, I wonder if it
is already disabled by default:

https://qa.debian.org/developer.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
https://buildd.debian.org/status/architecture.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Questions

[Paul Wise]

On Tue, 2018-12-04 at 21:34 +0100, Ruslanas Gžibovskis wrote:

> Paul Wise, what help is needed? I would like to commit, but not sure
> how, never done that, but would LOVE TO! Could you guide?

Check the pages I mentioned and look through each of them, there should
be enough documentation there for you to figure it out. Feel free to
ask any questions if something isn't clear.

If you're looking for info about using git, check out the docs:

https://git-scm.com/doc

Which area would you like to work on?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



signature.asc
Description: This is a digitally signed message part

Re: Questions

[Paul Wise]

On Mon, Dec 3, 2018 at 7:10 PM Jérôme Bardot wrote:

> Why debian is not more harden by default ?

We need more people who are interested in working on this topic, some
links for anyone who is interested in contributing:

https://security-tracker.debian.org/tracker/data/report
https://www.debian.org/security/audit/
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
https://www.debian.org/security/
https://wiki.debian.org/Hardening
https://wiki.debian.org/Hardening/Daemons
https://wiki.debian.org/Hardening/RepoAndImages
https://wiki.debian.org/Hardening/Goals

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Gaps in security coverage?

[Paul Wise]

On Wed, Nov 7, 2018 at 6:28 AM Moritz Mühlenhoff wrote:

> E.g. your specific example of busybox/CVE-2011-5325 is fixed in the
> upcoming stretch point release.

I noticed that this isn't reflected in the security tracker website
but it is in data/next-point-update.txt.

If anyone wants to get involved in enhancing the security tracker this
would probably be an ideal place to start.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Gaps in security coverage?

[Paul Wise]

On Tue, Nov 6, 2018 at 7:01 PM Holger Levsen wrote:

> is there a bug or wiki page describing the issues/requirements for that and
> what has been tried / the status?

Woops, I should have included that in the mail:

Bug#908678: security-tracker - Breaks salsa.d.o
https://bugs.debian.org/908678

--
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Gaps in security coverage?

[Paul Wise]

On Mon, 2018-11-05 at 20:52 -0600, John Goerzen wrote:

> That is good advice, thanks.  I've been a DD for a long while, but it's
> been awhile (years) since I've been involved in the security process and
> wasn't quite sure what the flow was anymore.

It is still mostly the same but the security team try to distribute
more work to the package maintainers especially for unstable.

> What kind of automated sources are you talking about here?  Where do I
> find the source that might be relevant?  I might be able to pitch in
> here.

Basically if you follow the manual commits to the security tracker repo
and think about how to automate each commit. The Mitre CVE data is
automatically imported but there are various sources of non-CVE data or
per-project data that has lower latency. I wrote down some possible
sources of data in check-external/sources.ini but never got around to
going further and the security team didn't seem to like the idea at all
so I've basically dropped it for now.

Also, a much more important task is restructuring the git repo so that
it doesn't cause responsiveness and resource usage issues with salsa.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



signature.asc
Description: This is a digitally signed message part

Re: Gaps in security coverage?

[Paul Wise]

On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote:

> Hi folks,

FTR, in case you were trying to contact the Debian Security Team
directly I suggest using secur...@debian.org or
t...@security.debian.org instead, debian-security is more of a general
security discussion list than a Debian Security Team list.

> So I recently started running debsecan on one of my boxes.  It's a
> fairly barebones server install, uses unattended-upgrades and is fully
> up-to-date.  I expected a clean bill of health, but didn't get that.  I
> got pages and pages and pages of output.  Some of it (especially kernel
> related) I believe may be false positives, but not all.  Some of it
> simply isn't patched yet.

That has been the normal state of things since I started running
debsecan many many years ago.

> Diving into it a bit, it seems that somehow we fell down a bit with
> stretch.  The first hit on my list is this one:
>
> https://security-tracker.debian.org/tracker/CVE-2011-5325
>
> Marked fixed in jessie, vulnerable in stretch.  And indeed when looking
> at the bug report 802702, I don't see any such changelog entries
> pertaining to this in my stretch version.

You can see at the bottom of this issue:

[stretch] - busybox  (Minor issue)

This means that the security team determined it is not an important
enough issue for them to fix in stable, but the maintainer could still
fix it in a point release if they cared.

> 1) Is this a symptom of a bad process or of not enough volunteers?  In
> other words, could we have marked these security bugs fixed in jessie as
> RC for stretch somehow until they were also fixed there?

I would guess mostly a lack of volunteers and also we need to give
package maintainers more responsibility for fixing the issues.

> 2) Is there a need for more help with security in general?  If so, what
> kinds of volunteering would be appreciated?

First rule of FLOSS (that also applies to Debian): more help is needed
in almost every area of almost every project.

>From the help Debian page:

https://www.debian.org/intro/help

You can help track, find and fix security issues within the packages in Debian.

https://security-tracker.debian.org/tracker/data/report
https://www.debian.org/security/audit/
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security

You can also help harden packages, repositories and images and other things.

https://wiki.debian.org/Hardening
https://wiki.debian.org/Hardening/RepoAndImages
https://wiki.debian.org/Hardening/Goals

Personally, I think running debsecan, looking at each item, pinging
bug reports and maintainers, doing stable updates and unstable NMUs,
pushing patches upstream etc would be a great help.

Also, debsecan itself could use a lot of help, the maintenance of it
and addition of new features currently falls on already-busy security
team folks.

In addition some more automation of ingestion of security info into
the security tracker would free up security team time that is
currently spent on manually updating the security-tracker data.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian HTTP repo got manipulated , Debian HTTPs repo doesnt work

[Paul Wise]

On Tue, Oct 23, 2018 at 12:33 AM bo0od wrote:

> yay! , yeah it worked thx alot :)

In addition, we have some Tor-based Onion services available:

https://onion.debian.org/

PS: this mailing list is about the security-tracker.debian.org site,
not about Debian mirrors or their security so please ask any further
questions about them on debian-user.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#908678: security-tracker - Breaks salsa.d.o

[Paul Wise]

On Thu, Sep 13, 2018 at 7:37 PM, Salvatore Bonaccorso wrote:

> Do you have any hints at us on what we could look at to faciliate/help
> more salsa maintainers?

I think I read on IRC that the main thing is that the design of git is
not optimised for having large and growing files that change on every
commit. So splitting them up into to one file per CVE/DSA/DLA/etc
might help? Or switching from git to a database or something like
restic or borg.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#907723: link package versions on security-tracker to source packages

[Paul Wise]

On Sat, Sep 1, 2018 at 5:53 PM, Holger Levsen wrote:
> On Sat, Sep 01, 2018 at 12:43:58PM +0800, Paul Wise wrote:
>> > So, I always go to [1] with my web browser, copy the URL of the .dsc file
>> > and then dget that .dsc file.
>> This misses out verifying apt signatures.
>
> the .dsc file is signed and dget verifies it.

dget does not verify the apt signatures though, since it does not download them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#907723: link package versions on security-tracker to source packages

[Paul Wise]

On Sat, Sep 1, 2018 at 5:48 AM, Mike Gabriel wrote:

> when working for the LTS team, I regularly need to download source packages
> from the LTS version of Debian. My development machine normally runs a newer
> Debian version, having deb-src URLs for Debian LTS in sources.list is
> possible but not a good option (for me) as it increases latency for apt
> update.

I would suggest you use either apt-venv or chdist (from devscripts) to
enable you to have the apt metadata for LTS and stable releases so
that you can easily download the source using apt. I do this and have
a cron job to automatically run apt update for each chdist.

> So, I always go to [1] with my web browser, copy the URL of the .dsc file
> and then dget that .dsc file.

This misses out verifying apt signatures.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: what do people think about having sandsifter in debian ?

[Paul Wise]

On Thu, Aug 16, 2018 at 8:50 AM, shirish शिरीष wrote:

> First of all thank you for the whole team for keeping Debian as secure
> as the people on the team do to keep Debian free from controversy ( at
> least from the security viewpoint) .

A few clarifications:

debian-security@lists.debian.org is not the contact address for the
Debian Security Team.

The Debian Security Team does not do packaging of security audit tools.

The Debian Security Tools Packaging Team is responsible for that:

https://wiki.debian.org/Teams/pkg-security
https://lists.debian.org/debian-security-tools/

> I just came upon sandsifter today. While I have done an RFP on it ,
> could people have a look at it.

RFPs are not sent anywhere useful by default, you should try to
X-Debbugs-CC the relevant teams if you want others to package
something, or just package it yourself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#898196: python-arrow: New version breaks autopkgtests of python-jsonext and rekall in testing

[Paul Gevers]

Source: python-arrow
Version: 0.12.1-1
Severity: serious
Control: affects -1 src:python-jsonext
Control: affects -1 src:rekall
User: debian...@lists.debian.org
Usertags: breaks

On 08-05-18 13:28, Paul Gevers wrote:
> Dear maintainers,
> 
> [This e-mail is automatically sent. V1 (20180508)]
> 
> As recently announced [1] Debian is now running autopkgtests in testing
> to check if the migration of a new source package causes regressions. It
> does this with the binary packages of the new version of the source
> package from unstable.
> 
> With a recent upload of python-arrow the autopkgtest of python-jsonext
> started to fail in testing [2]. This is currently delaying the migration
> of python-arrow version 0.12.1-1 [3].
> 
> This e-mail is meant to trigger direct communication between the
> maintainers of the involved packages as one party has insight in what
> changed and the other party insight in what is being tested. After all,
> a regression in a reverse dependency can be due to one of the
> following reasons (of course not complete):
> * new bug in the candidate package (fix the package)
> * bug in the test case that only gets triggered due to the update (fix
>   the reverse dependency, but see below)
> * out-of-date reference date in the test case that captures a former bug
>   in the candidate package (fix the reverse dependency, but see below)
> * deprecation of functionality that is used in the reverse dependency
>   and/or its test case (discussion needed)
> Triaging tips are being collected on the Debian Wiki [4].
> 
> Unfortunately sometimes a regression is only intermittent. Ideally this
> should be fixed, but it may be OK to just have the autopkgtest retried
> (a link is available in the excuses [3]).
> 
> There are cases where it is required to have multiple packages migrate
> together to have the test cases pass, e.g. when there was a bug in a
> regressing test case of a reverse dependency and that got fixed. In that
> case the test cases need to be triggered with both packages from
> unstable (reply to this e-mail and/or contact the ci-team [5]) or just wait
> until the aging time is over (if the fixed reverse dependency migrates
> before that time, the failed test can be retriggered [3]).
> 
> Of course no system is perfect. In case a framework issue is suspected,
> don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to
> me is also fine for initial cross-check).
> 
> To avoid stepping on peoples toes, this e-mail does not automatically
> generate a bug in the BTS, but it is highly recommended to forward this
> e-mail there (psuedo-header boilerplate below [6,7]) in case it is
> clear which package should solve this regression.
> 
> [1] https://lists.debian.org/debian-devel-announce/2018/05/msg1.html
> [2] https://ci.debian.net/packages/p/python-jsonext/testing/amd64/
> [3] https://qa.debian.org/excuses.php?package=python-arrow
> [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips
> [5] #debci on oftc or debian...@lists.debian.org
> [6] python-arrow has an issue
> 
> Source: python-arrow
> Version: 0.12.1-1
> Severity: normal or higher
> Control: affects -1 src:python-jsonext
> User: debian...@lists.debian.org
> Usertags: breaks
> 
> [7] python-jsonext has an issue
> 
> Source: python-jsonext
> Version: 0.4.1-1
> Severity: normal or higher
> Control: affects -1 src:python-arrow
> User: debian...@lists.debian.org
> Usertags: needs-update
> 

It turns out that the error in the log is the same for python-jsonext
and rakall, copied below. Looking at it, it seems one can't even import
the main library in python2.

ImportError: No module named functools_lru_cache

Paul

autopkgtest [03:16:51]: test smoke-python2:  - - - - - - - - - - stderr
- - - - - - - - - -
Traceback (most recent call last):
  File "debian/tests/smoke_test.py", line 121, in 
exit_status = main(sys.argv)
  File "debian/tests/smoke_test.py", line 112, in main
suite(args)
  File "debian/tests/smoke_test.py", line 74, in suite
emit_module(module_name)
  File "debian/tests/smoke_test.py", line 56, in emit_module
module = importlib.import_module(name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/python2.7/dist-packages/jsonext/__init__.py", line 13,
in 
from .mixins import JSONDateTimeMixin, JSONIterableMixin,
JSONToDictMixin, \
   File "/usr/lib/python2.7/dist-packages/jsonext/mixins.py", line 2, in

import arrow
  File "/usr/lib/python2.7/dist-packages/arrow/__init__.py", line 3, in

from .arrow import Arrow
  File "/usr/lib/python2.7/dist-packages/arrow/ar

Re: New version of python-arrow breaks autopkgtests of rekall in testing

[Paul Gevers]

Resent again because the original e-mail bounced for the Debian Forensic
team and the second address I got was wrong.

On 08-05-18 13:28, Paul Gevers wrote:
> Dear maintainers,
> 
> [This e-mail is automatically sent. V1 (20180508)]
> 
> As recently announced [1] Debian is now running autopkgtests in testing
> to check if the migration of a new source package causes regressions. It
> does this with the binary packages of the new version of the source
> package from unstable.
> 
> With a recent upload of python-arrow the autopkgtest of rekall
> started to fail in testing [2]. This is currently delaying the migration
> of python-arrow version 0.12.1-1 [3].
> 
> This e-mail is meant to trigger direct communication between the
> maintainers of the involved packages as one party has insight in what
> changed and the other party insight in what is being tested. After all,
> a regression in a reverse dependency can be due to one of the
> following reasons (of course not complete):
> * new bug in the candidate package (fix the package)
> * bug in the test case that only gets triggered due to the update (fix
>   the reverse dependency, but see below)
> * out-of-date reference date in the test case that captures a former bug
>   in the candidate package (fix the reverse dependency, but see below)
> * deprecation of functionality that is used in the reverse dependency
>   and/or its test case (discussion needed)
> Triaging tips are being collected on the Debian Wiki [4].
> 
> Unfortunately sometimes a regression is only intermittent. Ideally this
> should be fixed, but it may be OK to just have the autopkgtest retried
> (a link is available in the excuses [3]).
> 
> There are cases where it is required to have multiple packages migrate
> together to have the test cases pass, e.g. when there was a bug in a
> regressing test case of a reverse dependency and that got fixed. In that
> case the test cases need to be triggered with both packages from
> unstable (reply to this e-mail and/or contact the ci-team [5]) or just wait
> until the aging time is over (if the fixed reverse dependency migrates
> before that time, the failed test can be retriggered [3]).
> 
> Of course no system is perfect. In case a framework issue is suspected,
> don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to
> me is also fine for initial cross-check).
> 
> To avoid stepping on peoples toes, this e-mail does not automatically
> generate a bug in the BTS, but it is highly recommended to forward this
> e-mail there (psuedo-header boilerplate below [6,7]) in case it is
> clear which package should solve this regression.
> 
> [1] https://lists.debian.org/debian-devel-announce/2018/05/msg1.html
> [2] https://ci.debian.net/packages/r/rekall/testing/amd64/
> [3] https://qa.debian.org/excuses.php?package=python-arrow
> [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips
> [5] #debci on oftc or debian...@lists.debian.org
> [6] python-arrow has an issue
> 
> Source: python-arrow
> Version: 0.12.1-1
> Severity: normal or higher
> Control: affects -1 src:rekall
> User: debian...@lists.debian.org
> Usertags: breaks
> 
> [7] rekall has an issue
> 
> Source: rekall
> Version: 1.6.0+dfsg-2
> Severity: normal or higher
> Control: affects -1 src:python-arrow
> User: debian...@lists.debian.org
> Usertags: needs-update
> 
> 





signature.asc
Description: OpenPGP digital signature

Re: [SECURITY] [DSA 4187-1] linux security update

[Paul Wise]

On Thu, May 3, 2018 at 4:53 PM, richard lucassen wrote:

> There is also an big increase in time before random is initialized:
...
> One of the consequences is that openntpd (or a program like
> rdate) hangs until the crng is initialized.

What do these two programs require entropy for?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: RFS: zodbpickle/0.6.0-1 [ITP]

[Paul Wise]

On Mon, 2018-04-23 at 22:17 +0200, Julien Muchembled wrote:

> I suggest to update embedded-code-copies because this package forks
> the 'pickle' modules of Python 2.7.6 and 3.3.2

> python2.7
> - zodbpickle  (embed)
> NOTE: embeds stdlib modules: pickle, cpickle
> 
> I am surprised to see no entry for any version of Python 3.
> Maybe start one with python3.6

Added both.

> However, given the warning at the top of 
> https://docs.python.org/3/library/pickle.html
> I am not sure it's useful to bother about the security of this code.
> 
> And unfortunately, the many changes in Python are not merged into zodbpickle.

I'd suggest that you work with ZODB upstream to remove zodbpickle from
their dependencies/codebase. It is technical debt, problematic for
security and there are likely faster ways to serialise data in Python.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: pulling in other vulnerability databases

[Paul Wise]

On Thu, 2018-01-25 at 11:05 -0500, Antoine Beaupré wrote:

> I'm not sure what to say to nodesecurity.io folks

I've already contacted them multiple times in 2014 and once in 2016,
about incorporating CVEs into their workflow. The responses were
positive but didn't result in much change, except when the issues were
sent to oss-sec or Mitre by the Debian security team or myself or
others. Most of their recent advisories have CVEs but some don't. I'm
guessing the researchers who discovered the issues are getting CVEs.
I think the best outcome would be if NodeSecurity could become a CNA so
they could issue CVEs immediately with each advisory they send out.

https://marc.info/?i=1399944995.3095.25.camel@chianamo
https://marc.info/?i=1411952951.6106.20.ca...@bonedaddy.net
https://marc.info/?l=oss-security=139757263925026=2
http://www.openwall.com/lists/oss-security/2016/02/20/2
http://www.openwall.com/lists/oss-security/2016/01/12/2

> pabs, did you have any issues in mind that were problematic here
> specifically?

Here is one example culled from my email archive:

http://bugs.debian.org/862712
https://nodesecurity.io/advisories/338
https://security-tracker.debian.org/tracker/862712

It didn't end up getting added to the security tracker, didn't get a
CVE and only got fixed in Debian after I filed a bug about it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

[PATCH] Accept more variants of standard CVE identifier format

[Paul Wise]

Transform the given identifier to a standard one and
redirect to the standard form if it is in the database:

* convert spaces to dashes
* convert lowercase to uppercase
---
 bin/tracker_service.py | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/bin/tracker_service.py b/bin/tracker_service.py
index 9cbbccc8be..5a890f561d 100755
--- a/bin/tracker_service.py
+++ b/bin/tracker_service.py
@@ -329,9 +329,9 @@ data source.""")],
 return RedirectResult(self.url_debian_bug(url, str(bugnumber)),
   permanent=False)
 
-if 'A' <= obj[0] <= 'Z':
-# Bug names start with a capital letter.
-return self.page_bug(url, obj, redirect)
+page = self.page_bug(url, obj, redirect)
+if page is not None:
+return page
 
 if self.db.isSourcePackage(c, obj):
 return RedirectResult(self.url_source_package(url, obj, full=True))
@@ -339,20 +339,23 @@ data source.""")],
 return self.page_not_found(url, obj)
 
 def page_bug(self, url, name, redirect):
+# Transform the name to a standard one
+name_s = name.replace(' ', '-').upper()
+
 # FIXME: Normalize CAN-* to CVE-* when redirecting.  Too many
 # people still use CAN.
-if redirect and name[0:4] == 'CAN-':
-name = 'CVE-' + name[4:]
+if redirect and name_s[0:4] == 'CAN-':
+name_s = 'CVE-' + name_s[4:]
 
 cursor = self.db.cursor()
 try:
-bug = bugs.BugFromDB(cursor, name)
+bug = bugs.BugFromDB(cursor, name_s)
 except ValueError:
 if redirect:
-if name[0:4] == 'CVE-':
-return RedirectResult(self.url_cve(url, name),
+if name_s[0:4] == 'CVE-':
+return RedirectResult(self.url_cve(url, name_s),
   permanent=False)
-return self.page_not_found(url, name)
+return None
 if bug.name <> name or redirect:
 # Show the normalized bug name in the browser address bar.
 return RedirectResult(url.scriptRelativeFull(bug.name))
-- 
2.15.1

Re: Security Tracker Frame Options Header

[Paul Wise]

On Fri, Jan 12, 2018 at 4:59 PM, Mattia Dorigatti wrote:

> I have a question. Why do the security tracker sites have the 
> X-Frame-Options:sameorigin header set? Because I've wanted to keep an eye on 
> some CVEs I've created a simple html site with three iframes and the refresh 
> meta tag so that I could put it on an extra monitor and have a look at the 
> status. But I can't do that if that header is set. Why is this and can it be 
> changed?

All debian.org hosts use this header where possible. As you can see in
the Mozilla documentation, it is used to prevent clickjacking attacks
as well as hosts passing off content as their own, so I'm not sure it
is a good idea to disable it. I think it might be best for you to use
a browser extension to achieve the autorefresh and open a window for
each CVE. You could also just subscribe to the Debian bug mail for
each bug associated with the CVEs you are interested in.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
https://www.debian.org/Bugs/Developer#subscribe

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Is packages build without verifying the source package signatures?

[Paul Wise]

On Sat, Dec 2, 2017 at 7:15 PM, Davide Prina wrote:

> If I don't mistake the automatic package build system don't require that the
> source signature is verified correctly.

To clarify what Adam said; there are two times where source package
verification can happen during builds. The first is during "Download
source files with APT", which verifies hashes of the source files
against the hashes known for those files by apt, the keys for this
stage are the archive keys. The second is during "Unpack source",
which runs dpkg-source to extract the source package and (if all
Debian package uploader keys are installed) verifies the signature of
the source package matches a known developer key.

The Debian buildds only do the first verification (due to all Debian
package uploader keys not being installed) but the Debian archive
verifies that all uploads match a known developer key before passing
packages to the buildds. So in practice, both verifications are
happening, but not in the same place.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: HTTPS enabled Debian Security repository

[Paul Wise]

On Thu, 2017-11-09 at 11:30 +0100, Marek Sebera wrote:

> Is this up-to-date repository or manually synced mirror?

Neither, it is a pair of CDNs, hosted by Fastly and Amazon, although
only the Amazon CDN supports https.

> Also note I had to set ... as trused in system certificates

Normally it already would be.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: HTTPS enabled Debian Security repository

[Paul Wise]

On Thu, Nov 9, 2017 at 5:57 PM, Marek Sebera wrote:

> Thank you for support, so is the https enabled repository coming up?

One of the CDNs backing deb.d.o supports https, see the last para here:

http://deb.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: HTTPS enabled Debian Security repository

[Paul Wise]

On Thu, Oct 26, 2017 at 4:43 PM, Marek Sebera wrote:

> please advise, is there any repository, that is both official mirror of
> security.debian.org and enabled with SSL (HTTPS) access?

One of the CDNs backing deb.d.o supports https, see the last para here:

http://deb.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Different MD5 from same kernel module tun.ko on different servers same distro

[Paul Wise]

On Sun, Sep 3, 2017 at 9:17 AM, x9p wrote:

> the differences between both files doesn't look that much (vimdiff on xxd
> output below), just wondering what might have caused such differences
> between the same kernel module, from the same package, same distribution.

A better tool to compare binaries is diffoscope, it can disassembles
ELF binaries and compare the assembly.

Please upload the two tun.ko files to the trydiffoscope website so
that we can investigate the differences more closely:

https://try.diffoscope.org/

>   00037a0: 2f62 7569 6c64 2f6c 696e 7578 2d31 774a  /build/linux-1wJ   |
> 00037a0: 2f62 7569 6c64 2f6c 696e 7578 2d63 6835  /build/linux-ch5
>   00037b0: 4f58 392f 6c69 6e75 782d 332e 3136 2e34  OX9/linux-3.16.4   |
> 00037b0: 3366 412f 6c69 6e75 782d 332e 3136 2e34  3fA/linux-3.16.4
>
>   0003870: 696e 7578 2d31 774a 4f58 392f 6c69 6e75  inux-1wJOX9/linu   |
> 0003870: 696e 7578 2d63 6835 3366 412f 6c69 6e75  inux-ch53fA/linu
>
>   00038a0: 2f62 7569 6c64 2f6c 696e 7578 2d31 774a  /build/linux-1wJ   |
> 00038a0: 2f62 7569 6c64 2f6c 696e 7578 2d63 6835  /build/linux-ch5
>   00038b0: 4f58 392f 6c69 6e75 782d 332e 3136 2e34  OX9/linux-3.16.4   |
> 00038b0: 3366 412f 6c69 6e75 782d 332e 3136 2e34  3fA/linux-3.16.4

These look like they are two different builds of the Debian Linux
kernel package. If you or your cloud provider did not rebuild the
Debian Linux kernel package, then it is possible your cloud server has
been compromised and tun.ko modified with the version from a different
build of the package.

Are there any other modified files on the system? You can use debsums to check.

PS: I would suggest upgrading to Debian stretch at some point.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: STIG-4-Debian for Debian "Stretch" 9

[Paul Wise]

On Thu, Jun 29, 2017 at 6:19 PM, Samson wrote:

> I'm Samson-W, the "Captain" of the STIG-4-DEBIAN project in the
> HardenedLinux community. We basically implemented the similar functions of
> STIG RHEL-07 v1r1 to Debian 9. The project is located at github at:
> https://github.com/hardenedlinux/STIG-4-Debian

If you would like to get this into Debian, please read this page:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: heads-up: stretch release and changes to security-tracker

[Paul Wise]

On Mon, Jun 12, 2017 at 3:37 AM, Salvatore Bonaccorso wrote:

> I'm attaching the *preliminary* set of changes which I plan to
> activate once stretch is released.

Wow, there really is a horribly large amount of hard-coding of things
that should be fetched from the archive instead. I've added a
reference to your mail here:

https://wiki.debian.org/SuitesAndReposExtension#secure-testing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: heads-up: stretch release and changes to security-tracker

[Paul Wise]

On Sat, May 27, 2017 at 5:06 PM, Chris Lamb wrote:

> Can you briefly explain what changes you are refering to?

If appropriate, please document the hard-coding here too:

https://wiki.debian.org/SuitesAndReposExtension

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Certificate errors with security.debian.org

[Paul Wise]

On Sun, Jan 15, 2017 at 1:41 PM, Tea Wrex wrote:

> I am unable to make HTTPS connections to https://security.debian.org/

security.d.o has never supported https. Some of the machines behind it
also host other services, some of which support https, which is why
you get certificate errors.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252

[Paul Wise]

On Fri, Dec 16, 2016 at 4:33 AM, Patrick Schleizer wrote:

> Is it possible to disable InRelease processing by apt-get?

The answer from #debian-apt is that there is no setting for this.

Your options are:

Use an intercepting proxy that replies with 404 to InRelease files.

Do an apt update to download InRelease/Release/Release.gpg using apt
and then manually verify them with gpg before doing the upgrade.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Handling of "malware" in Debian

[Paul Wise]

On Wed, 2016-11-09 at 16:17 +0100, W. Martin Borgert wrote:

> Would NEWS.Debian be sufficient?

My intuition says that there are users who don't have apt-listchanges
installed or don't read the NEWS files. The most likely place folks
will see the notification is in the UI of the malware package itself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: how to apply the fix for CVE-2016-5195

[Paul Wise]

On Mon, Oct 24, 2016 at 9:02 PM, Omar Abu Ajamieh wrote:

>  i have multiple Debian servers with this kernel version ( 3.2.0-4-amd64 #1
> SMP Debian 3.2.63-2 ) and i’m trying to fix the CVE-2016-5195 on it ,so
> could please help me in how i can determine if my server is vulnerable or
> not and how i can apply the fix on it ?

Upgrade your packages and then reboot. More info here:

https://lists.debian.org/debian-lts-announce/2016/10/msg00026.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Activate your GlobalTestMarket membership

[Paul Wise]

On Sun, Oct 2, 2016 at 7:28 PM, jm33_m0 wrote:

> What the hell...

Please don't reply to spam nor quote it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [SECURITY] [DSA 3660-1] chromium-browser security update

[Paul Wise]

On Tue, Sep 6, 2016 at 7:32 AM, Raúl Cuza wrote:

> Is there a web link with this info?

https://www.debian.org/security/2016/dsa-3660 (not yet online)
https://security-tracker.debian.org/tracker/DSA-3660-1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Reserved CVEs

[Paul Wise]

On Fri, Sep 2, 2016 at 5:59 PM, Ivan Vasylivskyi wrote:

> Why some vulnerabilities listed by Ubuntu Security Tracker which are public
> and populated marked as RESERVED on mitre.org ?

This mailing list is for the Debian Security Tracker, not the Ubuntu
security tracker.

A lot of the time the vulnerabilities are publicly released elsewhere
before Mitre makes them public on their site.

> Can I compile the list of vulnerabilities is update them on mitre.org ?

Not sure what you mean by that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: DSA for CVE-2016-5696 (off-path blind TCP session attack)

[Paul Wise]

On Tue, Aug 16, 2016 at 2:42 AM, Sam Morris wrote:

> And if you like the article, consider subscribing to LWN!

Especially since they are in need of new subscribers:

https://lwn.net/Articles/696017/

> I'm pretty sure there's a group membership available to all DDs anyway.

That is for both Debian members and Debian Maintainers:

https://wiki.debian.org/MemberBenefits#LWN

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: flashplugin-nonfree and latest Flash security updates

[Paul Wise]

On Wed, Aug 3, 2016 at 8:29 AM, Nick Boyce wrote:

> I have emailed the maintainer (Bart Martens, at his debian.org address)
> twice about this (30th.July and 1st.Aug), but there has been no reply as
> yet. Do I need to post to the bug report Francesco mentioned:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820583
> rather than emailing Bart directly ?

Mailing the bug report will send a mail to Bart directly.

> I realise the nonfree plugin is not really supported, but given the
> serious (!!!) security implications of running a known-vulnerable Flash
> player for a significant time after a fixed version has been released,
> and assuming Bart is MIA for some reason, is it possible for the
> Security Team to either fix the update, or to make an announcement that
> all Debian users should stop using the Adobe player immediately ?

I'm not part of the team, but I do know that contrib and non-free are
not supported by the Debian security team, so they are unlikely to
make any fixes nor announcements.

https://www.debian.org/security/faq#contrib

I'd encourage everyone reading this list to use this opportunity
transition away from using the Adobe Flash player. Most of the web
should support standard HTML5 by now, various folks have been pushing
to get rid of Flash for a long time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Call for testing: upcoming wordpress security update

[Paul Wise]

On Tue, Aug 2, 2016 at 11:27 PM, donoban wrote:

> Not so world-writable:
> "Account creation failed: Due to an ongoing spam attack, this wiki is
> configured to not automatically create wiki accounts for some users.
> Please contact w...@debian.org first if you wish to create an account,
> and describe what you want to do in the wiki.."

I've just whitelisted your email now so things should work OK if you
try to register again. Please let us know if you have any problems.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: "Ian Murdock" Death

[Paul R. Tagliamonte]

Yeah.

https://twitter.com/CVaillance/status/752613020325425153

Either a solid troll, keeping this up as a 24/7 persona, or isn't there,
mentally.

Please stop responding.

On Jul 16, 2016 10:25 AM, "Jakub Wilk"  wrote:

> * Kyle Lussier , 2016-07-16, 07:15:
>
>> I request people put "extra mental bandwidth" into responses
>>
>
> I request that people don't feed the troll. Thanks.
>
> --
> Jakub Wilk
>
>

Re: [SECURITY] [DSA 3613-1] libvirt security update

[Paul Staroch]

Am 2016-07-02 um 15:00 schrieb Edgar Pettijohn:

Can we remove Jung from the list. This is quite annoying.

Sent from my iPhone


I'd appreciate it if someone who is responsible for the 
debian-security-announcements mailing list could care for bug #821113 [1].


The amount of auto-responder spam on debian-security has become annoying 
during the last few days.



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821113

Re: 9n216.13.107.82

[Paul Wise]

On Thu, Jun 9, 2016 at 5:50 PM, Joel Rees wrote:

> Can I suggest to those who responded to these that kneejerk reactions
> aren't useful?

The people who got the spam with a spoofed address are unlikely to be
subscribed to this list.

> FTR, we assume that someone was spoofing luciano's email address,
> either randomly or as an attack on his character.

Spoofing email addresses is a common spammer tactic.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: DMCRYPT question

[Paul Wise]

On Sat, May 21, 2016 at 1:34 PM, Ralph Sanchez wrote:

> I was just wandering, as what Ive read thus far doesn't explicitly
> say, when you configure encryption during the install, does that
> implement LUKS or must that be done after wards during normal use??>

It uses LUKS, you can read more about it here:

https://wiki.debian.org/DebianInstaller/PartmanCrypto

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Which Debian packages leak information to the network?

[Paul Wise]

On Fri, May 20, 2016 at 12:42 AM, Paul Wise wrote:

> Debian probably needs a privacy team to audit all packages that send
> data to the network and develop mitigation, configuration or patches
> to counter these.

Looks like there are a few related teams but they are mostly about tools:

https://wiki.debian.org/DebianPrivacy
https://wiki.debian.org/DebianSanctuary
https://wiki.debian.org/Teams/AnonymityTools

If someone wants to organise a BoF at DebConf16 I will be willing to
attend and brainstorm this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Which Debian packages leak information to the network?

[Paul Wise]

On Wed, May 18, 2016 at 11:50 PM, Patrick Schleizer wrote:

> Hello we are a privacy-centric distro based on Debian and wanted to know
> what Debian packages leak information about the system to the network
> without a user's consent/expectation.

Debian probably needs a privacy team to audit all packages that send
data to the network and develop mitigation, configuration or patches
to counter these.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Which Debian packages leak information to the network?

[Paul Wise]

On Thu, May 19, 2016 at 7:56 AM, georg wrote:
> On 16-05-18 16:54:27, Holger Levsen wrote:
>> gnome-calculator contacts a web page/service with currency exchange
>> information *on every start*,
>
> Is this "publicly" known? Is this discussed with the upstream devs?

https://bugzilla.gnome.org/show_bug.cgi?id=741828

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian SHA-1 deprecation

[Paul Wise]

On Wed, May 18, 2016 at 9:20 PM, Daniel Pocock wrote:

> Can anybody comment on how Debian users will be impacted by SHA-1
> deprecation?

There is some info related to that in these two wiki pages:

https://wiki.debian.org/SHA-1
https://wiki.debian.org/Teams/Apt/Sha1Removal

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: please add icdiff to embedded-code-copies

[Paul Wise]

On Mon, May 16, 2016 at 5:17 AM, Sascha Steinbiss wrote:

> as the maintainer, I’d like to let you know the package ‘icdiff’ (new in 
> unstable) contains a modified fork of Python’s difflib code. According to 
> upstream, it’s "based on Python's difflib.HtmlDiff, with changes to provide 
> console output instead of HTML output".

Thanks, committed.

> icdiff
> - libpython-stdlib  (modified-embed)
> NOTE: core functionality based on Python difflib code with changed 
> output format

FYI, the format is the other way around and deals with source
packages. Also, I think icdiff is more of a fork than modified-embed?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: bug reports for grub need to be re-posted

[Paul Wise]

On Fri, May 13, 2016 at 8:12 PM, Elmar Stellnberger wrote:

>   Hi! Would anyone mind to re-post the following bug reports at
> https://savannah.gnu.org/bugs/?

That URL gives a 404 message.

> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23498
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23490
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23496
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23497

Apparently these are all not bugs and won't be fixed?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23498;msg=9

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: tracking security issues without CVEs

[Paul Wise]

On Mon, Mar 28, 2016 at 10:34 PM, Andrew Deck wrote:

> On a related note, does anyone know what happened to OSF and the OSVDB?
> There still seem to be blog updates, but I remember OSVDB having a web
> UI, and the OSF website seems to be down.

They have officially closed the OSVDB site:

https://blog.osvdb.org/2016/04/05/osvdb-fin/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: tracking security issues without CVEs

[Paul Wise]

On Mon, Mar 28, 2016 at 10:34 PM, Andrew Deck wrote:

> On a related note, does anyone know what happened to OSF and the OSVDB?
> There still seem to be blog updates, but I remember OSVDB having a web
> UI, and the OSF website seems to be down.

They have officially closed the OSVDB site:

https://blog.osvdb.org/2016/04/05/osvdb-fin/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [SECURITY] [DSA 3558-1] openjdk-7 security update

[Paul Eger]

Unsubscribe please
On 26 Apr 2016 10:28 pm, "Moritz Muehlenhoff"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> - -
> Debian Security Advisory DSA-3558-1   secur...@debian.org
> https://www.debian.org/security/   Moritz Muehlenhoff
> April 26, 2016https://www.debian.org/security/faq
> - -
>
> Package: openjdk-7
> CVE ID : CVE-2016-0636 CVE-2016-0686 CVE-2016-0687 CVE-2016-0695
>  CVE-2016-3425 CVE-2016-3426 CVE-2016-3427
>
> Several vulnerabilities have been discovered in OpenJDK, an
> implementation of the Oracle Java platform, resulting in breakouts of
> the Java sandbox, denial of service or information disclosure.
>
> For the stable distribution (jessie), these problems have been fixed in
> version 7u101-2.6.6-1~deb8u1.
>
> We recommend that you upgrade your openjdk-7 packages.
>
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/
>
> Mailing list: debian-security-annou...@lists.debian.org
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJXH837AAoJEBDCk7bDfE42T0QP+QGxR+OgBILJHNJTKzZEaCH0
> vVuYoMqnPOJAauIxkeT42iDd9r3lIIYDtwM1QmGYAcJpC+i70qwXdufFNOJoXZ+q
> nd57UdI2ggnzHkCwqzqQt7BFgOJ+o0VqXuXuezWErdHAIoTN8H0uE9vQJ4Le0ASj
> VmKAzNO49ZMhDxrXOTDRFEZCEF2c2+cQ4y5w7Jfs1m1KxWpkQ9MlbQrXtJJYHR2d
> opvW9ifTLpND9lAir2TD0oB826g9kY2HySc90e6GxK7Y8l9n2l2eUNYcka2b4DXb
> wu/xCrvdB5B4czDXzMJGbo59upsh9u4DOTZpt2I2oWgxDR6wodNHCla4ExfGokOg
> TJmO6PYSNuzUQNkXqt7SfME09DfoMBLFSvZ1Rj58whM4XaT15MRkHFXtW/qQPD3i
> jOGVVRFn9o0961o6QXe+GrMd6/GfOX9/iK7wapH9Zozpd8Tftp73ZvDsxZseH+vF
> lrT8oI7cdLO5vqHeFTahcz0wIVsTFpC6unHW/0ivcBSy58G90BYC3qEU3UebAkfd
> 6h0GNfC9x5xL2vmHHKYgdgRqrmdUdJlgS5s2ay4SE4cLXoaFOBgT7OK76VDobkYO
> TAmvUGrFCeMuNKc1l5p+nLCG5F3RnogDONNXjWSwlM6NSjIm/C6YLoAYYXJrjYXB
> G699bO+MYk5QquS65HJx
> =Rabo
> -END PGP SIGNATURE-
>
>

Re: fighting spam

[Paul Wise]

On Mon, Apr 25, 2016 at 6:28 PM, Davide Prina wrote:

> I think this is a very bad solution.
..
> I think the actual policy is the best one.

Debian already uses RBLs to block spam from the lists, another one
wouldn't be anything new.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: fighting spam

[Paul Wise]

On Fri, Apr 22, 2016 at 6:14 PM, SZÉPE Viktor wrote:

> Please consider using http://psky.me/ to keep spam out of the list.

The people running the Debian lists can be contacted here:

https://www.debian.org/MailingLists/#maintenance

I've forwarded your suggestion to them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Urgent Card REF#726925

[Paul Wise]

On Fri, Apr 22, 2016 at 6:56 AM, james robinson wrote:

> Oooo

Please do not reply to spam and especially do not quote spam in your own mails.

The from address in the spam you received was obviously forged. Press
the junk button in your MUA and move on.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Github users

[Paul Wise]

On Fri, Apr 15, 2016 at 2:40 AM, jack wrote:

> Has this subscriber (list-abuser) been de-listed and banned, or do I
> need to take action on my own behalf?

Please do not reply to spam and especially do not quote spam in your own mails.

To report spam on the mailing lists, please click the "Report spam"
button in the list archives.

Debian mailing lists are not restricted to subscribers.

Banning one spammer address usually won't have any effect since
spammers don't use single addresses.

The Debian listmasters have been asked to add a rule to block these
kinds of "list sellers" spam mails.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Call for testing: upcoming samba security update

[Paul Wise]

On Thu, Apr 14, 2016 at 6:03 PM, Vladislav Kurz wrote:

> I have noticed that samba-common-bin now depends on samba. It didn't before
> the upgrade. Is there any special reason for that? I just need nmblookup on
> some servers (and smbclient/cifs) but not the server package.

This has been fixed in the latest update.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [SECURITY] [DSA 3541-1] roundcube security update

[Paul Wise]

On Wed, Apr 6, 2016 at 2:08 AM, donoban wrote:

> Of course I would like to help

Some links to ways you can help with Debian security:

https://security-tracker.debian.org/tracker/data/report
https://www.debian.org/security/audit/
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
https://www.debian.org/security/
https://wiki.debian.org/Hardening
https://wiki.debian.org/Hardening/RepoAndImages
https://wiki.debian.org/Hardening/Goals

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Remove email

[Paul Tagliamonte]

That's not an appropriate response, Daniel,

Please do not continue doing such rude things on Debian project resources.
Thank you.



Tiffany - you can unsubscribe by sending an email to the unsubscription
email, or by using the following webform:

https://www.debian.org/MailingLists/unsubscribe

Thanks!
  Paul

On Thu, Mar 31, 2016 at 11:07 AM, DANIEL ROMO <danielromogar...@gmail.com>
wrote:

> mv tiffanyryan2...@gmail.com /dev/null
>
> 2016-03-31 9:42 GMT-05:00 Tiffany Ryan <tiffanyryan2...@gmail.com>:
>
>> Please remove my email from you system
>>
>> tiffanyryan2...@gmail.com
>>
>
>
>
> --
>
>
> "La imaginación es más importante que el conocimiento. Einstein"
>
>
> *Daniel Romo*
> *SysAdmin* / Linit.biz <http://linit.biz>
>
>
> d4nnr.blogspot.com.co #Blog_Personal
>



-- 
:wq