Unfortunately we have a security regression in 1.5.0 - public in
https://github.com/linux-pam/linux-pam/pull/298
and
https://github.com/linux-pam/linux-pam/pull/300
Should we obtain CVE id for that and release 1.5.1 asap? The severity is low/medium as the issue affects only systems where the root account already has blank password but the root login can be blocked by other means in theory so I do not think we can dismiss it as a security issue fully.
Hi,
On Mon, Nov 23, Tomas Mraz wrote:
Unfortunately we have a security regression in 1.5.0 - public in
https://github.com/linux-pam/linux-pam/pull/298
and
https://github.com/linux-pam/linux-pam/pull/300
Should we obtain CVE id for that and release 1.5.1 asap? The severity is low/medium as the issue affects only systems where the root account already has blank password but the root login can be blocked by other means in theory so I do not think we can dismiss it as a security issue fully.
We should release 1.5.1 asap, but I don't think we need a CVE for this.
Thorsten
-- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Pam-developers mailing list -- pam-developers@lists.fedorahosted.org To unsubscribe send an email to pam-developers-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/pam-developers@lists.fedorahost...
On Mon, 2020-11-23 at 10:49 +0100, Thorsten Kukuk wrote:
Hi,
On Mon, Nov 23, Tomas Mraz wrote:
Unfortunately we have a security regression in 1.5.0 - public in
https://github.com/linux-pam/linux-pam/pull/298
and
https://github.com/linux-pam/linux-pam/pull/300
Should we obtain CVE id for that and release 1.5.1 asap? The severity is low/medium as the issue affects only systems where the root account already has blank password but the root login can be blocked by other means in theory so I do not think we can dismiss it as a security issue fully.
We should release 1.5.1 asap, but I don't think we need a CVE for this.
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 10:49 +0100, Thorsten Kukuk wrote:
Hi,
On Mon, Nov 23, Tomas Mraz wrote:
Unfortunately we have a security regression in 1.5.0 - public in
https://github.com/linux-pam/linux-pam/pull/298
and
https://github.com/linux-pam/linux-pam/pull/300
Should we obtain CVE id for that and release 1.5.1 asap? The severity is low/medium as the issue affects only systems where the root account already has blank password but the root login can be blocked by other means in theory so I do not think we can dismiss it as a security issue fully.
We should release 1.5.1 asap, but I don't think we need a CVE for this.
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 10:49 +0100, Thorsten Kukuk wrote:
Hi,
On Mon, Nov 23, Tomas Mraz wrote:
Unfortunately we have a security regression in 1.5.0 - public in
https://github.com/linux-pam/linux-pam/pull/298
and
https://github.com/linux-pam/linux-pam/pull/300
Should we obtain CVE id for that and release 1.5.1 asap? The severity is low/medium as the issue affects only systems where the root account already has blank password but the root login can be blocked by other means in theory so I do not think we can dismiss it as a security issue fully.
We should release 1.5.1 asap, but I don't think we need a CVE for this.
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
On Mon, Nov 23, 2020 at 01:09:33PM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 10:49 +0100, Thorsten Kukuk wrote:
Hi,
On Mon, Nov 23, Tomas Mraz wrote:
Unfortunately we have a security regression in 1.5.0 - public in
https://github.com/linux-pam/linux-pam/pull/298
and
https://github.com/linux-pam/linux-pam/pull/300
Should we obtain CVE id for that and release 1.5.1 asap? The severity is low/medium as the issue affects only systems where the root account already has blank password but the root login can be blocked by other means in theory so I do not think we can dismiss it as a security issue fully.
We should release 1.5.1 asap, but I don't think we need a CVE for this.
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
Yes, please try.
On Mon, 2020-11-23 at 16:19 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 01:09:33PM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
Yes, please try.
We have allocated CVE-2020-27780 for this issue. I'll merge the PR after amending the commit with the CVE number.
On Tue, 2020-11-24 at 14:49 +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 16:19 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 01:09:33PM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
Yes, please try.
We have allocated CVE-2020-27780 for this issue. I'll merge the PR after amending the commit with the CVE number.
Heh, I forgot I've already merged it. I'll add a NEWS entry.
On Tue, Nov 24, 2020 at 02:51:41PM +0100, Tomas Mraz wrote:
On Tue, 2020-11-24 at 14:49 +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 16:19 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 01:09:33PM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
IMO if we regard this as security issue we should get CVE number. Only in case we do not regard it as such - i.e. we think it is just plain regression bug we should not get CVE.
My personal opinion is that this is a security issue although low or medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
Yes, please try.
We have allocated CVE-2020-27780 for this issue. I'll merge the PR after amending the commit with the CVE number.
Heh, I forgot I've already merged it. I'll add a NEWS entry.
Great. Are we ready for the release now?
On Tue, 2020-11-24 at 17:36 +0300, Dmitry V. Levin wrote:
On Tue, Nov 24, 2020 at 02:51:41PM +0100, Tomas Mraz wrote:
On Tue, 2020-11-24 at 14:49 +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 16:19 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 01:09:33PM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote:
> IMO if we regard this as security issue we should get CVE > number. > Only > in case we do not regard it as such - i.e. we think it is > just > plain > regression bug we should not get CVE. > > My personal opinion is that this is a security issue > although > low > or > medium one only. But I can be persuaded otherwise.
This regression in pam_unix may have security implications, so let's treat it this way.
To make a release, we need an updated NEWS file, and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
Yes, please try.
We have allocated CVE-2020-27780 for this issue. I'll merge the PR after amending the commit with the CVE number.
Heh, I forgot I've already merged it. I'll add a NEWS entry.
Great. Are we ready for the release now?
I think we should release ASAP so we do not introduce another regression by merging further stuff. :D
On Wed, Nov 25, 2020 at 12:53:22PM +0100, Tomas Mraz wrote:
On Tue, 2020-11-24 at 17:36 +0300, Dmitry V. Levin wrote:
On Tue, Nov 24, 2020 at 02:51:41PM +0100, Tomas Mraz wrote:
On Tue, 2020-11-24 at 14:49 +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 16:19 +0300, Dmitry V. Levin wrote:
On Mon, Nov 23, 2020 at 01:09:33PM +0100, Tomas Mraz wrote:
On Mon, 2020-11-23 at 14:04 +0300, Dmitry V. Levin wrote: > On Mon, Nov 23, 2020 at 11:53:56AM +0100, Tomas Mraz wrote: > > > IMO if we regard this as security issue we should get CVE > > number. > > Only > > in case we do not regard it as such - i.e. we think it is > > just > > plain > > regression bug we should not get CVE. > > > > My personal opinion is that this is a security issue > > although > > low > > or > > medium one only. But I can be persuaded otherwise. > > This regression in pam_unix may have security implications, > so let's treat it this way. > > To make a release, we need an updated NEWS file, > and it seems appropriate to mention the CVE number there.
Should I try to get the CVE number from our Product Security team?
Yes, please try.
We have allocated CVE-2020-27780 for this issue. I'll merge the PR after amending the commit with the CVE number.
Heh, I forgot I've already merged it. I'll add a NEWS entry.
Great. Are we ready for the release now?
I think we should release ASAP so we do not introduce another regression by merging further stuff. :D
OK, I'll proceed with the release now.
pam-developers@lists.fedorahosted.org