Reposman.rb does not consider underscore to be valid char for a project identifier (Bug #270)

I don't see a need to recheck the project identifiers as they are already checked before being written to the DB. Furthermore, the paths are constructed using the ruby built-in File, so there should be no problem with "funny characters" should we extend the allowed character space later on.

Holger, Eric: could one of you have a quick look and confirm we can completely remove the checks for identifier presence and well-formedness?

I already talked to Jens about this. I pretty sure we are save here, as the repo names are returned from the ChiliProject. So we should be save if we trust the ChiliProject instance to not lie to us.

However, (and that just occurred to me) we should probably check the path nevertheless, in case the ChiliProjet instance is not telling the truth. This could be achieved with something like the following snippet which protects us against path traversal attacks. The rest should already be handled by the rest of the checks. This snippet saves us from having to hardcode the check regex again.

1require 'pathname'
2unless Pathname.new(repos_path).cleanpath.to_s.start_with? $repos_base
3  log("\tinvalid identifier for project #{project.name} : #{project.identifier}");
4  next;
5end

Holger Just wrote:

However, (and that just occurred to me) we should probably check the path nevertheless, in case the ChiliProjet instance is not telling the truth.

+1, that was my first thought last week (though I guess I never posted it ;)). If someone changes identifiers in the database, it bypasses our validations and could cause reposman.rb to cause some havoc.

Another option is to have the server check that each project is valid before sending data to reposman.rb. That would keep the logic in the server and will let reposman.rb become more of a dumb client.

Chili 1.2 is due by the end of next week. This is a bug, that can be easily fixed. While there seems to be uncertainty about the future workings of repository integration in Chili, I think we should, at first, just fix this bug.

I propose to use https://github.com/ulferts/chiliproject/commit/8f839e1a7217990d857c22043812d69d796c3ac8 since it has the littlest impact and should therefor cause no unforeseen side effects.

A rework/refactoring/redesign of repository integration should not be part of a minor release. Perhaps, we should talk about that topic in the forums.