Bug#821408: Pam 1.3.0
Hello Steve and Andreas,
On Thu, Jan 24, 2019 at 12:10:18AM +0100, Florian Vessaz wrote:
[...]
> I'll take the time to review those differences tomorrow or Friday night.
I compared the two branches:
[a] https://gitlab.gnugen.ch:fvessaz/pkg-pam.git ah/master
[b] https://salsa.debian.org/ah/pam.git master
The differences I observed are:
- Changelog entry for version 1.3.1-1 are different, the one in [b]
looks better to me.
- [a] contains patches metadata (author, date) retrieved from VCS
history or BTS while [b] does not.
- In patches/007_modules_pam_unix, [b] is is not adding the "obscure"
argument which gates the functionality added by that same patch.
- In patches/055_pam_unix_nullok_secure, [a] adds the "int nullok =
off(UNIX__NONULL, ctrl);" at the tail of the list of already present
declarations at the start of the if block while [b] adds it at the
top. As far as I can tell, both versions have the same result and
there is no apparent advantage of one over the other:
[a] static char *envp[] = { NULL };
const char *args[] = { NULL, NULL, NULL, NULL };
int nullok = off(UNIX__NONULL, ctrl);
[b] int nullok = off(UNIX__NONULL, ctrl);
static char *envp[] = { NULL };
const char *args[] = { NULL, NULL, NULL, NULL };
Another difference is that [a] does not use an implicit declaration of
_pammodutil_tty_secure. [b] is thus triggering an additional implicit
declaration warning during the build.
Finally, it appears that [b] was not adapted to the change made
upstream to how unix_args is defined in modules/pam_unix/support.h.
- In patches/PAM-manpage-section, [a] is doing pam.8.xml -> pam.7 ->
PAM.7 while [b] is doing pam.8.xml -> pam.8 -> PAM.7. Same result in
both cases.
I updated [a] to do as [b] since [b] is changing less lines for the
same result. Thus, at the time you are reading this e-mail, this
difference will not be present.
- patches/cve-2010-4708.patch is still included in [b] while upstream
settled the issue in pam 1.1.3. As the patch description does not
provide any argument for keeping it despite upstream settling the
issue, [a] dropped it. If it is preferred to keep the patch, in my
opinion the patch description should mention the reason.
- In patches/make_documentation_reproducible.patch [a] uses
"LC_ALL=C.UTF-8" while [b] uses "LC_ALL=C". Usage of "LC_ALL=C.UTF-8"
was introduced by 4b9ee4f1ec73d87668ce40f0a362ecbc58159d9f.
- In patches/update-motd [a] clarifies a sentence.
Please let me know if my branch should be updated, I can take the time
to do so if I receive feedback. And don't hesitate to replace my commit
with the changelog entry.
Thank you,
-- Florian
signature.asc
Description: PGP signature
Bug#821408: Pam 1.3.0
Hello Andreas and Steve, On Wed, Jan 23, 2019 at 01:29:07PM +0100, Andreas Henriksson wrote: > Hello Florian and Steve, > > On Tue, Jan 22, 2019 at 02:40:00PM -0800, Steve Langasek wrote: > > On Tue, Jan 22, 2019 at 09:12:31PM +0100, Florian Vessaz wrote: > > > We've got no reply from the current maintainers to this bug report since > > > the approximately 2 and a half years it has been opened. I thus think > > > it's safe to presume the current maintainers have no interest in keeping > > > PAM up-to-date in Debian. > > Sorry for not having found time to look at this. I'm still very > interested in seeing improvements on the PAM side, I'm just very short > on spare time. > > FWIW I think the chance for getting changes into buster has most likely > passed already. Atleast I wouldn't feel comfortable introducing alot > of changes this late in the release cycle. I think it's better to target > experimental now and then upload to unstable early in the bullseye > cycle. I'll see what happens when Buster is released, but it currently appears to me that not having a reasonably up-to-date version of PAM available might, for me, be a deal breaker that will make me reconsider my usage and support of Debian. > > Wow, that's an incredible conclusion less than 2 weeks after a maintainer > > upload. > > [...] > > (I appreciate your past efforts to handle this migration, but in your own > > words "the history of the packaging is not pretty" and I was unwilling to > > accept an incomplete history of the packaging.) > > Thanks for joining the discussion. I'm sure we can elaborate eternally > on our definitions of "properly maintaining" and the tradeoffs between > pretty git histories and having users suffer the consequenses of > the outstanding bugs for yet another release cycle, but lets proceed > to something more productive. Thank you for joining, I'm glad that it finally looks possible to get an up-to-date PAM version included in Debian. I would have greatly appreciated to have gotten a feedback on my contribution from 2 years ago instead of it being totally ignored. During those two years, I had more than enough time that would have enabled me to improve my contribution if I had received a feedback. I'm also sure everyone who took the time to open bug reports would appreciate for those bug reports to be followed up. Anyway, let's focus on the present. > [...] > > Anyway, consider this an objection to salvaging of the pam package. Is this a confirmation from your part that you now have the motivation and time available in order to upload up-to-date PAM versions and properly answer the bug reports that pilled up over the years? > > I am happy to take a look at your work to forward-port the patches onto pam > > 1.3. Would you be willing to rebase > > https://gitlab.gnugen.ch/fvessaz/pkg-pam.git onto > > https://salsa.debian.org/vorlon/pam.git ? > > As it's not a trivial rebase to do I've "recreated" much of it on top > of the new git repo. Cherry-picking from Florians tree where possible, > reimporting the upstream release from scratch, using my own tree > of patches from my previous effort[1], and resolved conflicts where > they appeared when cherry-picking, added some new commits as well. > In other words, credits to Florian and blame for breakage should > likely be assigned to me. > > My result is thus not exactly equivalent to Florians tree. Diffing > debian/patches between our trees can be an interesting read as it's > two independent rebasing of the existing patches. > > Please see https://salsa.debian.org/ah/pam/commits/ah/master > > (see also the ah/upstream branch.) I also took the time to work on my branch in order to get something to compare and to ensure I have an understanding of the changes. I also included the commit you added to update debian/watch. See https://gitlab.gnugen.ch/fvessaz/pkg-pam, the master branch is the updated one and 2018/master is the one from December. I did not update the changelog entry I previously added; yours might be more appropriate. I only took the time to have a cursory look at the differences today. However, it currently appears that they are relatively small and contained in debian/patches. I'll take the time to review those differences tomorrow or Friday night. > Hoping we can make progress here because the things I'm interested > in seeing fixed are still to come (but to find motivation to try to > allocate the time there needs to be some signs of it having a chance > to be a useful investment). I'm, also hoping we can make progress. :-) Cheers, -- Florian signature.asc Description: PGP signature
Bug#821408: Pam 1.3.0
Hello Florian and Steve, On Tue, Jan 22, 2019 at 02:40:00PM -0800, Steve Langasek wrote: > On Tue, Jan 22, 2019 at 09:12:31PM +0100, Florian Vessaz wrote: > > We've got no reply from the current maintainers to this bug report since > > the approximately 2 and a half years it has been opened. I thus think > > it's safe to presume the current maintainers have no interest in keeping > > PAM up-to-date in Debian. Sorry for not having found time to look at this. I'm still very interested in seeing improvements on the PAM side, I'm just very short on spare time. FWIW I think the chance for getting changes into buster has most likely passed already. Atleast I wouldn't feel comfortable introducing alot of changes this late in the release cycle. I think it's better to target experimental now and then upload to unstable early in the bullseye cycle. > > Wow, that's an incredible conclusion less than 2 weeks after a maintainer > upload. > > It happens that fly-by NMUs are a lot less work than properly maintaining a > package. So yes, there were a series of NMUs from developers who had no > investment in the long-term maintainability of the package in the time it > took me to get the VCS history converted into something supported and do a > maintainer upload. > > (I appreciate your past efforts to handle this migration, but in your own > words "the history of the packaging is not pretty" and I was unwilling to > accept an incomplete history of the packaging.) Thanks for joining the discussion. I'm sure we can elaborate eternally on our definitions of "properly maintaining" and the tradeoffs between pretty git histories and having users suffer the consequenses of the outstanding bugs for yet another release cycle, but lets proceed to something more productive. [...] > Anyway, consider this an objection to salvaging of the pam package. > > I am happy to take a look at your work to forward-port the patches onto pam > 1.3. Would you be willing to rebase > https://gitlab.gnugen.ch/fvessaz/pkg-pam.git onto > https://salsa.debian.org/vorlon/pam.git ? As it's not a trivial rebase to do I've "recreated" much of it on top of the new git repo. Cherry-picking from Florians tree where possible, reimporting the upstream release from scratch, using my own tree of patches from my previous effort[1], and resolved conflicts where they appeared when cherry-picking, added some new commits as well. In other words, credits to Florian and blame for breakage should likely be assigned to me. My result is thus not exactly equivalent to Florians tree. Diffing debian/patches between our trees can be an interesting read as it's two independent rebasing of the existing patches. Please see https://salsa.debian.org/ah/pam/commits/ah/master (see also the ah/upstream branch.) Hoping we can make progress here because the things I'm interested in seeing fixed are still to come (but to find motivation to try to allocate the time there needs to be some signs of it having a chance to be a useful investment). Regards, Andreas Henriksson [1]: https://people.debian.org/~ah/pkg-pam/
Bug#821408: Pam 1.3.0
On Tue, Jan 22, 2019 at 09:12:31PM +0100, Florian Vessaz wrote: > We've got no reply from the current maintainers to this bug report since > the approximately 2 and a half years it has been opened. I thus think > it's safe to presume the current maintainers have no interest in keeping > PAM up-to-date in Debian. Wow, that's an incredible conclusion less than 2 weeks after a maintainer upload. It happens that fly-by NMUs are a lot less work than properly maintaining a package. So yes, there were a series of NMUs from developers who had no investment in the long-term maintainability of the package in the time it took me to get the VCS history converted into something supported and do a maintainer upload. (I appreciate your past efforts to handle this migration, but in your own words "the history of the packaging is not pretty" and I was unwilling to accept an incomplete history of the packaging.) > The following points are taken from the Debian Developer's Reference > document mentioned above: > * NMUs, especially if there has been more than one NMU in a row. > Since the 18th of April 2016, date at which this bug was opened there was: > 2016-06-02 1.1.8-3.3 NMU > 2016-12-20 1.1.8-3.4 NMU > 2017-01-04 1.1.8-3.5 NMU > 2017-05-27 1.1.8-3.6 NMU > 2018-02-07 1.1.8-3.7 NMU > 2018-08-13 1.1.8-3.8 NMU > 2019-01-09 1.1.8-4 upload by a maintainer I think this is poorly worded in the DevRef. Clearly the intent is that there be several /unacknowledged/ NMUs. Anyway, consider this an objection to salvaging of the pam package. I am happy to take a look at your work to forward-port the patches onto pam 1.3. Would you be willing to rebase https://gitlab.gnugen.ch/fvessaz/pkg-pam.git onto https://salsa.debian.org/vorlon/pam.git ? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#821408: Pam 1.3.0
Hi Andreas, On Thu, Dec 06, 2018 at 11:44:14AM +0100, Andreas Henriksson wrote: > Hi Florian, > > On Mon, Dec 03, 2018 at 10:13:23PM +0100, Florian Vessaz wrote: > [...] > > I updated my Git repository such that it now contains pam 1.3.1, the > > changes from the previous NMUs, your changes and additional small > > changes to address some of the lintian warnings. > > Thanks for doing that and for still being interested. > I'll try to find time and motivation to look over your new version > soon. (Please feel free to poke me if I seem to have forgotten about > this.) Thank you for trying. I suppose you might not have found the time or might not have the motivation. Which is perfectly fine, there are no obligations. > [...] > > I haven't really looked at the available options to get the changes > > uploaded. So any pointers would be welcomed. :-) > > I assume you're not a DD, so unless current pam maintainers show > any interest I guess it's up to me to review your stuff and then > I think it would be quite harmless if we upload it to experimental. We've got no reply from the current maintainers to this bug report since the approximately 2 and a half years it has been opened. I thus think it's safe to presume the current maintainers have no interest in keeping PAM up-to-date in Debian. [...] > Please see here if you're > interested in the administrative details on how it should be > done properly these days: > > https://wiki.debian.org/PackageSalvaging > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging The following points are taken from the Debian Developer's Reference document mentioned above: * NMUs, especially if there has been more than one NMU in a row. Since the 18th of April 2016, date at which this bug was opened there was: 2016-06-02 1.1.8-3.3 NMU 2016-12-20 1.1.8-3.4 NMU 2017-01-04 1.1.8-3.5 NMU 2017-05-27 1.1.8-3.6 NMU 2018-02-07 1.1.8-3.7 NMU 2018-08-13 1.1.8-3.8 NMU 2019-01-09 1.1.8-4 upload by a maintainer * Bugs filed against the package do not have answers from the maintainer. 9 out of the 15 first bugs displayed on the BTS page appear to have been neglected for more than a year. I did not inspect the other bug reports. https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pam No answer since #917374 December 2018 Important #916169 December 2018 Important #914541 November 2018 Important #890626 February 2018 Normal #890524 February 2018 Important #889910 February 2018 Important #824607 May 2017 Normal #834589 August 2016 Important #332292 June 2013 Important #583958 May 2013 Normal #691008 October 2012 Normal #601825 November 2010 Important #569746 February 2010 Important #336513 October 2005 Important #182605 July 2008 Normal * Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged. This bug reports asked for an up-to-date version of PAM in April 2016. In February 2017, I proposed an updated package including PAM 1.3.0 but no feedback was received from the maintainers. In December 2018, I proposed an updated package including PAM 1.3.1 but no feedback was received from the maintainers. The version currently in Debian is 1.1.8 which has been released by upstream in September 2013. So, it appears to me that the Package Salvaging process is applicable. It's is however unclear to me if the Package Salvaging process can be performed by someone like me who is not a DD or a DM. As it is defined in the Debian Developer's Reference, I presume the process is to be performed by a DD. Is there a chance to get an up-to-date version of PAM in Buster? Cheers, -- Florian signature.asc Description: PGP signature
Bug#821408: Pam 1.3.0
Hi Florian, On Mon, Dec 03, 2018 at 10:13:23PM +0100, Florian Vessaz wrote: [...] > I updated my Git repository such that it now contains pam 1.3.1, the > changes from the previous NMUs, your changes and additional small > changes to address some of the lintian warnings. Thanks for doing that and for still being interested. I'll try to find time and motivation to look over your new version soon. (Please feel free to poke me if I seem to have forgotten about this.) [...] > I haven't really looked at the available options to get the changes > uploaded. So any pointers would be welcomed. :-) I assume you're not a DD, so unless current pam maintainers show any interest I guess it's up to me to review your stuff and then I think it would be quite harmless if we upload it to experimental. In the olden days we'd then battle it out for ownership, but since recently there's a new official procedure how to go about this which I should read up on myself. Please see here if you're interested in the administrative details on how it should be done properly these days: https://wiki.debian.org/PackageSalvaging https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging Regards, Andreas Henriksson
Bug#821408: Pam 1.3.0
Hi Andreas, On Fri, Nov 09, 2018 at 01:17:45AM +0100, Andreas Henriksson wrote: > Hi Florian, > > On Sun, Feb 05, 2017 at 05:48:23PM +0100, Florian Vessaz wrote: > > Hi, > > > > I've refreshed the patches against the 1.3.0 release and moved the > > packaging to Git as upstream is also using Git. (This was discussed with > > Steve two weeks ago.) > [...] > > https://gitlab.gnugen.ch/fvessaz/pkg-pam.git > [...] > > I'm naturally open to constructive criticism. Let me know if there is > > something I can do to help out. > > I (unfortunately) just redid all of your work because I didn't > find this bug report because of the non-standard subject. :( > > OTOH I did against pam 1.3.1 so slightly newer. > See https://people.debian.org/~ah/pkg-pam/ > > I'm just at the point where it now builds. No further checks done yet. > > I guess we can always compare work to see if we did it the same. I updated my Git repository such that it now contains pam 1.3.1, the changes from the previous NMUs, your changes and additional small changes to address some of the lintian warnings. > Since a long time has passed, I'd like to ask if you are still > interested in working on pam in Debian? Yes, I'm interested in having an up-to-date pam in Debian. Over the last two years or so, I've just installed pam through other means to get the latest upstream versions. So if I instead spend time to keep the package updated, that would actually be more useful. > I think an upload to experimental would be a good start and I'm willing > to sponsor if there's a need. (If we continue from your work then > incorporating all the NMUs that happened since it was prepared is > also needed.) I haven't really looked at the available options to get the changes uploaded. So any pointers would be welcomed. :-) Cheers, -- Florian signature.asc Description: PGP signature
Bug#821408: Pam 1.3.0
Control: retitle -1 New upstream release available (1.3.1) Hi Florian, On Sun, Feb 05, 2017 at 05:48:23PM +0100, Florian Vessaz wrote: > Hi, > > I've refreshed the patches against the 1.3.0 release and moved the > packaging to Git as upstream is also using Git. (This was discussed with > Steve two weeks ago.) [...] > https://gitlab.gnugen.ch/fvessaz/pkg-pam.git [...] > I'm naturally open to constructive criticism. Let me know if there is > something I can do to help out. I (unfortunately) just redid all of your work because I didn't find this bug report because of the non-standard subject. :( OTOH I did against pam 1.3.1 so slightly newer. See https://people.debian.org/~ah/pkg-pam/ I'm just at the point where it now builds. No further checks done yet. I guess we can always compare work to see if we did it the same. Since a long time has passed, I'd like to ask if you are still interested in working on pam in Debian? I think an upload to experimental would be a good start and I'm willing to sponsor if there's a need. (If we continue from your work then incorporating all the NMUs that happened since it was prepared is also needed.) Regards, Andreas Henriksson
Bug#821408: Pam 1.3.0
Hi, I've refreshed the patches against the 1.3.0 release and moved the packaging to Git as upstream is also using Git. (This was discussed with Steve two weeks ago.) I've imported the packaging history from bzr. The history of the packaging is not pretty, but I don't think there is a reasonable way to fix it. You can fetch the relevant branches from this Git remote: https://gitlab.gnugen.ch/fvessaz/pkg-pam.git master: packaging branch upstream: upstream releases pam/master: upstream's master branch bzr/sid: https://alioth.debian.org/scm/loggerhead/pkg-pam/debian/sid The important tags are also here: debian/*: Debian releases upstream/*: Imports of upstream sources I believe the future releases can be imported using gbp-import-orig and the --upstream-vcs-tag option to link upstream's master branch. In my opinion it would be a good idea to push all that to Alioth but I can't do it myself as I'm just a long-time Debian user. ;-) I'm naturally open to constructive criticism. Let me know if there is something I can do to help out. Cheers, -- Florian signature.asc Description: PGP signature
