On Tue, 2019-01-22 at 13:17 +0100, Yves-Alexis Perez wrote:
> -------------------------------------------------------------------------
> Debian Security Advisory DSA-4371-1 security(a)debian.org
> https://www.debian.org/security/ Yves-Alexis Perez
> January 22, 2019 https://www.debian.org/security/faq
> -------------------------------------------------------------------------
>
> Package : apt
> CVE ID : CVE-2019-3462
>
> Max Justicz discovered a vulnerability in APT, the high level package manager.
> The code handling HTTP redirects in the HTTP transport method doesn't properly
> sanitize fields transmitted over the wire. This vulnerability could be used by
> an attacker located as a man-in-the-middle between APT and a mirror to inject
> malicous content in the HTTP connection. This content could then be recognized
> as a valid package by APT and used later for code execution with root
> privileges on the target machine.
> [...]
(This presumably needs to be fixed fairly quickly in PureOS, if only
for the PR.)
What is the way to expedite this?
Best wishes,
--
Chris Lamb
https://puri.sm
Chris Lamb wrote:
> > Package : apt
> > CVE ID : CVE-2019-3462
[…]
> (This presumably needs to be fixed fairly quickly in PureOS, if only
> for the PR.)
>
> What is the way to expedite this?
Ping on this too? :)
Best wishes,
--
Chris Lamb
https://puri.sm
Chris Lamb wrote:
> I just went to refresh my local copy of pureos/core/systemd.git and
> noticed that the Git history had completely diverged from my
> 238-5pureos1 upload of June 2018.
Ping on this?
Best wishes,
--
Chris Lamb
https://puri.sm
Hi Matthias (et al.)
I just went to refresh my local copy of pureos/core/systemd.git and
noticed that the Git history had completely diverged from my
238-5pureos1 upload of June 2018.
Indeed, looking at:
https://source.puri.sm/pureos/core/systemd/activity
.. it looks like the project was deleted and recreated, essentially
scrubbing the history of the aforementioned upload.
I'm not at all a "no history rewriting" snob but I was just
wondering if this was part of some semi-usual process I was unaware
of or a one-off in this particular case and it somehow was not
communicated to the rest of us folks.
Anyway, it would be good to learn if this could happen at the very
least. If this is indeed a possibility, please could you go ahead
and document that on the wiki and post a link back here? :)
Many thanks in advance.
Best wishes,
--
Chris Lamb
https://puri.sm
Hi,
Nicole shared with me this URL
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
from the Fedora mailing lists.
TL;DR; is that the new MongoDB license is not considered "free" by
Fedora and the question is if we ought to consider it non-free as well.
I feel that Fedora's conclusion is not necessarily unreasonable. I do
wonder what the impact might be but I suppose it might not be that
large given the installed base of PureOS. It may affect Debian more if
they decide they want to remove MongoDB.
I do think there is another question though; how do we decide what
stays in and what is kept out of PureOS? I feel we ought to curate our
selection of packages from Debian given our limited resources for
maintenance and since we're relying on Debian to do the type of license
checking and curation that Fedora is doing. While I think that is
reasonable given Debian's Free Software Guidelines it may not be
appropriate. For example, what if Purism's Liberty services wants to
use PureOS and they need MongoDB and have no problem with the license?
Relying on Debian will not always meet our needs. This points the need
for PureOS to be curated with regard to;
- Licenses
- Security
- Fitness for purpose
I think we'll need to try and come up with policies for each scope
above, even if they end up being "we do what Debian does" or "we rely
on Debian."
The URL Nicole shared seems to be a good example of where PureOS policy
might differ from our upstream. What is the view of folks here? Should
we keep on including MongoDB or should we stop?
Regards,
Jeremiah
Hi Jeremiah,
> The URL Nicole shared seems to be a good example of where PureOS policy
> might differ from our upstream. What is the view of folks here?
My view is that our "upstream" is Debian, and unless I am missing
something, we should just follow their lead here. As it happens,
will almost-certainly mean its removal. See, the two Debian bugs in
question:
https://bugs.debian.org/915537https://bugs.debian.org/916107
No need to write or curate policies until we see a need, a request
or a lack of clarity, no?
Best wishes,
--
Chris Lamb
https://puri.sm