Hi, Philipp Kern <[email protected]> wrote: > There's not only lack of common sense in security, there's also > ignorance and offensive behaviour.
You couldn't be nicer... thanks! :) Seriously, it's not what you are saying. I'm aware of offensive behaviors of users/hackers, but DTC isn't small (maybe 100k lines total, if you account all the components). It's not a lack of knowledge or understanding. It's just some pieces of code that have gone under the radar, because of the overall size of the project. Also, sometimes, you are reading at the code, feel there's a problem, but can't see it. That was the case for the logPushlet issue when I receive the contribution. > In case that the bug numbers are not obvious: #614302, #614304, > #611680, #414480, #566654. We're going more than 4 years in the past here, with some being false positive. I don't really see the point, every software has issue, and I don't think mine has a higher rate of problems than others. But let's comment, since the package is being pointed at. #614302 and #566650 has been fixed and released for a long time. #614304 have been fixed in my Git for a long time, and I worked on it as soon as it has been reported (using SHA-1 hashing, which I perfectly know isn't perfect, but that's the only one available in MySQL right now). I don't think it would have been reasonable to rush for releasing a fix. I was carefully preparing a release, which I was planning to do over the next weeks. I have learned the hard way that I shouldn't hurry releasing because it can lead to serious breakage, so please don't hold me for that. #611680 isn't relevant and has no impact, as written on the BTS. #566654 I believe, isn't more dangerous than the /etc/mysql/debian.cnf. So unless /etc/mysql/debian.cnf is removed from Debian, fixing #566654 is useless, IMHO. #616359 I have no clue how this happened, it doesn't with my setups, and never has. But anyway the plan was to remove the symlinks creation all together, and prevent the use of /path/of/example.com in the favor of /path/of/example.com/subdomains/www only, since I believe giving access to higher level directory of chroot, even if it's less convenient, it is also less safe. But I had no time to work on that code removal yet. I didn't comment on it, maybe I should have, because it seem that it's very similar to #637482 that you reported as well (eg: the issue is the hostname of the server not being configured correctly, and "hostname --domain" not replying anything, which isn't a DTC issue per say, but more an administrator issue). So yes, it looks bad if you see from far, but please look closer, and you see these aren't as terrible as you are claiming. At least, I don't think they should weight on the removal of the package. > The newest ones are #637485, #637477, #637469 and #637487. No, of > course you couldn't have replied to those yet, but they show some > general issues with the code and the packaging. All of them are already fixed in my Git. Just for the record, #637477 and #637487 were contribution which I didn't inspect enough. For #637487, in the same file, I can remember that at the time, I added lots of checks that the original author forgot. But it seems I missed the echo ones. That code was done years ago, and I believe that since, I care a lot more checking contributions. Alexander Reichle-Schmehl <[email protected]> wrote: > Does the phrase "We Won't Hide Problems" ring a bell for you? Sure it does. But at the same time, can you please confirm that you are claiming it's not good practice to warn an author about issues before revealing it publicly? I never said we should hide problems, and I approve the social contract and DFSG. Anyone can ask me to approve it anytime again if he wishes, I still stand for it. I just think it would have been reasonable to ask for few days to fix security issues, like it happened in the past, and I think it's quite admitted to be good practices, even in Debian. > PS: Also note that dtc isn't part of a stable release, so what's the > problem with opening security related bugs? There's thousands of installation of DTC around the world, some using our private Debian backport repository. My company does hosting with DTC, and so does many others all around the world. It really can have serious consequences. Now, let me take a step back and try to comment on the big picture. To make things clear: I do understand that these last MySQL and shell insertion are really serious issues with grave consequences, and I agree that some parts of the code is sloppy to say the least. I am the one to blame for sure, for not looking enough at contributions and re-factoring code enough. I really don't want you guys to think that I'm not taking it seriously. I'd like however that you understand that a lot of work has been recently (over let's say the last 2 years), to re-factor the code. And that this work will continue. I am perfectly aware of the different configuration problems, and the fact that the setup script is really horrible. I don't like it either. Lots of people within Debian have seen it, commented on it, pointed finger at. But to date, absolutely nobody came to me with a solution that would work. I also would like to highlight that this is a distribution wide issue, with Debian Edu having the exact same troubles as I have. Never the less, since few weeks, and thanks to conversations and brainstorming during Debconf 11, I think I got an idea that might be close to a solution, with a system of trigers between packages. If all goes as planned, you might well hear about a new DEP out of this. If you want to discuss that topic, I'd be very happy to do so: it's not an easy one. Cheers, Thomas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
