On Mon, Oct 18, 2010 at 01:26:05PM -0400, Len Sorensen wrote: > On Fri, Sep 24, 2010 at 06:52:32PM -0400, Roger Leigh wrote: > > While this change is clearly an annoyance to yourself, the severity > > is certainly not grave, so I am changing it accordingly. If the > > change was causing irretrievable data loss, then the grave severity > > would have been appropriate. > > > > Your comments are also rather aggressive. Please keep to the facts, > > rather than using unnecessarily inflammatory language. It's not > > helpful, and is most certainly *not* appreciated. Bug reports should > > have the goal of improving the software, not abusing its developers. > > Please bear that in mind, both in any replies to this email, and in > > any future bug reports. > > Perhaps I was a bit too aggresive. I had a cold, it wasn't the first time > this year schroot had broken things that previously worked without even > a hint in the changelog that such breakage was being introduced. In noen > of the cases does there seem to be any good reason for breaking things. > To me these breakages are so severe that a NEWS entry should have popped > up warning the user that this was happening.
This is now documented in schroot's README.Debian file. It could also be put into NEWS.Debian. > I don't think breaking things this close to a release with the intent > of fixing it someday later is acceptable. Why should configs from Lenny > stop working when people move to Squeeze? Are you going to put that in > the release notes? Are you going to have debconf pop up a warning to > users that their configs are now potentially broken? We can put it into NEWS.Debian to have this in a more prominent place. > > • we will allow more permissive chroot naming once the security > > implications have been throughly evaluated, and the code > > audited > > So when is that going to happen? If it isn't before squeeze is finallized > then I think this change has to be reverted or at least vastly relaxed. > It breaks too much as it is. I'm currently writing my PhD thesis, and haven't got the time to commit to it to get this completed before squeeze. Squeeze is also frozen, though it might be possible to get this in given it's fixing a regression. It won't be reverted in the short term. As I said, it needs careful review before that will happen, and I can't commit to that for the next few months. I think the best approach at this point is to simply document the change more prominently in NEWS.Debian. > > • you are free to modify the source to make this change yourself, > > at entirely your own risk > > Well I had too, given I can't use it anymore without changing it. > It has become useless to me as shipped upstream. > > Certainly the filenames permitted by run-parts is way too restrictive > and not a good source of a regex to use. As I said, I'm in complete agreement. It's not ideal and it does need fixing. But safety and security are the main concern, and I'll fix it once they are addressed. > I will happily write up a regex if I knew everything it needs to consider. The particular regex isn't the issue. It's the matter of auditing all the code that uses filenames and chroot names to make sure it's secure. The regex is just enforcing the rules; we need to be sure the rest of the code is safe in addition so that we can guarantee it's secure when we do relax the regex. > Also, it seems wrong for schroot to refuse to use ANY chroot if there > is any chroot in any config with an "illegal" name. So you can't even > use the valid ones when any invalid ones are defined. That's also by design. If the configuration is broken, it needs fixing before we can be sure it's safe. We're merely erring on the side of caution so the user can't inadvertently do something with unintended catastrophic effects because the configuration was incorrect. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
