Re: MIR question: upstream code in main pulled in code we have in universe
On Sat, Feb 12, 2022 at 1:42 AM Steve Langasek wrote: > > On Fri, Feb 11, 2022 at 01:43:31PM -0300, Andreas Hasenack wrote: > > On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek > > wrote: > > > > On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote: > > > > Hi, I have a question for the MIR (Main Inclusion Request) team members, > > > > > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in > > > > code (regex.c file) from another upstream project[2], for which we > > > > have a package in universe: src:libnfsidmap-regex > > > > > Would this require another MIR review? I mean, in general, once a > > > > package is in main, we don't apply the MIR guidelines to it anymore, > > > > and they can usually change the code as the project sees fit. > > > > It just so happens this time we have this exact scenario where the > > > > code that was pulled already exists and is the sole purpose of > > > > another, universe, package. > > > > > My options are basically: > > > > a) have src:nfs-utils build bin:libnfsidmap-regex and remove > > > > src:libnfsidmap-regex from the archive > > > > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and > > > > keep building src:libnfsidmap-regex from universe as usual > > > > > Option (b) will incurr in delta with debian. I believe[3] Debian will > > > > eventually remove/obsolete src:libnfsidmap-regex > > > > > 1. > > > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461 > > > > 2. https://github.com/isginf/libnfsidmap-regex > > > > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20 > > > > I think you should submit it for an additional MIR review if and only if > > > there is reason to consider the new library security-sensitive. (If it's > > > a > > > library that will be used by one of the NFS daemons, that's a good reason > > > to > > > think it's security-sensitive.) > > > Yeah, it's an libnfsidmap plugin that applies regular expressions to > > NFSv4 usernames and group names that come over the wire in the form > > user@DOMAIN and group@DOMAIN. > > > What if I keep bin:libnfsidmap-regex, built from the new > > src:nfs-utils, in universe? With a remark in d/control that it should > > not be promoted to main without a specific new MIR? > > I think that's also acceptable. Indeed, if you have no dependency pulling it into main the binary can live in universe as it did before, just now built from another source. > -- > 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 > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: MIR question: upstream code in main pulled in code we have in universe
On Fri, Feb 11, 2022 at 01:43:31PM -0300, Andreas Hasenack wrote: > On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek > wrote: > > On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote: > > > Hi, I have a question for the MIR (Main Inclusion Request) team members, > > > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in > > > code (regex.c file) from another upstream project[2], for which we > > > have a package in universe: src:libnfsidmap-regex > > > Would this require another MIR review? I mean, in general, once a > > > package is in main, we don't apply the MIR guidelines to it anymore, > > > and they can usually change the code as the project sees fit. > > > It just so happens this time we have this exact scenario where the > > > code that was pulled already exists and is the sole purpose of > > > another, universe, package. > > > My options are basically: > > > a) have src:nfs-utils build bin:libnfsidmap-regex and remove > > > src:libnfsidmap-regex from the archive > > > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and > > > keep building src:libnfsidmap-regex from universe as usual > > > Option (b) will incurr in delta with debian. I believe[3] Debian will > > > eventually remove/obsolete src:libnfsidmap-regex > > > 1. > > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461 > > > 2. https://github.com/isginf/libnfsidmap-regex > > > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20 > > I think you should submit it for an additional MIR review if and only if > > there is reason to consider the new library security-sensitive. (If it's a > > library that will be used by one of the NFS daemons, that's a good reason to > > think it's security-sensitive.) > Yeah, it's an libnfsidmap plugin that applies regular expressions to > NFSv4 usernames and group names that come over the wire in the form > user@DOMAIN and group@DOMAIN. > What if I keep bin:libnfsidmap-regex, built from the new > src:nfs-utils, in universe? With a remark in d/control that it should > not be promoted to main without a specific new MIR? I think that's also acceptable. -- 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: MIR question: upstream code in main pulled in code we have in universe
Hi, On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek wrote: > > On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote: > > Hi, I have a question for the MIR (Main Inclusion Request) team members, > > > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in > > code (regex.c file) from another upstream project[2], for which we > > have a package in universe: src:libnfsidmap-regex > > > Would this require another MIR review? I mean, in general, once a > > package is in main, we don't apply the MIR guidelines to it anymore, > > and they can usually change the code as the project sees fit. > > It just so happens this time we have this exact scenario where the > > code that was pulled already exists and is the sole purpose of > > another, universe, package. > > > My options are basically: > > a) have src:nfs-utils build bin:libnfsidmap-regex and remove > > src:libnfsidmap-regex from the archive > > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and > > keep building src:libnfsidmap-regex from universe as usual > > > Option (b) will incurr in delta with debian. I believe[3] Debian will > > eventually remove/obsolete src:libnfsidmap-regex > > > 1. > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461 > > 2. https://github.com/isginf/libnfsidmap-regex > > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20 > > I think you should submit it for an additional MIR review if and only if > there is reason to consider the new library security-sensitive. (If it's a > library that will be used by one of the NFS daemons, that's a good reason to > think it's security-sensitive.) Yeah, it's an libnfsidmap plugin that applies regular expressions to NFSv4 usernames and group names that come over the wire in the form user@DOMAIN and group@DOMAIN. What if I keep bin:libnfsidmap-regex, built from the new src:nfs-utils, in universe? With a remark in d/control that it should not be promoted to main without a specific new MIR? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: MIR question: upstream code in main pulled in code we have in universe
On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote: > Hi, I have a question for the MIR (Main Inclusion Request) team members, > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in > code (regex.c file) from another upstream project[2], for which we > have a package in universe: src:libnfsidmap-regex > Would this require another MIR review? I mean, in general, once a > package is in main, we don't apply the MIR guidelines to it anymore, > and they can usually change the code as the project sees fit. > It just so happens this time we have this exact scenario where the > code that was pulled already exists and is the sole purpose of > another, universe, package. > My options are basically: > a) have src:nfs-utils build bin:libnfsidmap-regex and remove > src:libnfsidmap-regex from the archive > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and > keep building src:libnfsidmap-regex from universe as usual > Option (b) will incurr in delta with debian. I believe[3] Debian will > eventually remove/obsolete src:libnfsidmap-regex > 1. > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461 > 2. https://github.com/isginf/libnfsidmap-regex > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20 I think you should submit it for an additional MIR review if and only if there is reason to consider the new library security-sensitive. (If it's a library that will be used by one of the NFS daemons, that's a good reason to think it's security-sensitive.) -- 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
MIR question: upstream code in main pulled in code we have in universe
Hi, I have a question for the MIR (Main Inclusion Request) team members, New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in code (regex.c file) from another upstream project[2], for which we have a package in universe: src:libnfsidmap-regex Would this require another MIR review? I mean, in general, once a package is in main, we don't apply the MIR guidelines to it anymore, and they can usually change the code as the project sees fit. It just so happens this time we have this exact scenario where the code that was pulled already exists and is the sole purpose of another, universe, package. My options are basically: a) have src:nfs-utils build bin:libnfsidmap-regex and remove src:libnfsidmap-regex from the archive b) build src:nfs-utils without producing bin:libnfsidmap-regex, and keep building src:libnfsidmap-regex from universe as usual Option (b) will incurr in delta with debian. I believe[3] Debian will eventually remove/obsolete src:libnfsidmap-regex 1. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461 2. https://github.com/isginf/libnfsidmap-regex 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
