Redmine

Holger Just wrote:

This is not a security issue but is exactly how distributes version control systems (such as git or mercurial) work. Here, there is no inherent central authority which decides upon access restrictions or metadata.

Instead, with got and mercurial, each commit is first done to a local repository. Each commit will have various metadata attached to it such as the author, comitter, a timestamp, ...) This meta data can be freely set when performing the commit. Operations such a rebasing, you can even edit this later (which will produce a different commit ID). With git and mercurial, it is common to assemble commits from various sources (such as patch files, external repositories, scripts, ...) and then to push these commits to e.g. a Redmine-controlled git repository. In this case, a user who is authorized to push to a repository can push commits by any author. The author on the commits is just another metadata field which is not checked (by default) anywhere and which is just used for display purposes rather than for access checks.

With subversion, you have a different, centralized model. Here, the server-based repository is the central single point of truth. The author of a commit is necessarily the same person who "sends" the commit. As such, it makes sense to enforce the author field of subversion commits to be the authorized user who performs the commit (although you can configure the subversion server to not enforce this or to allow changing this later).

With that being said, if you truely need to strongly identify the author of a git commit later, git offers the possibility to sign commits with a PGP key. Although this information is not specifically processed by Redmine currently, it allows you to identify responsible persons later by checking the actual git repository.

Using a custom pre-receive hook on your server-side git repositories, you may also enforce further arbitrary rules. Here you could e.g. enforce that each commit is authored by currently authenticated user or that it is signed by a known PGP key. This however is outside the currently scope of Redmine.

that is interesting,

what i also noticed is that redmine replaces the user of the log with the full name of the user based on that information

example, given:

userid:fullname
joe: joe here
donald: donald there
both existing redmine users and

donald: donald athome
as a non existing redmine user, another donald, not the same as before but present in the log of the git project,

so suppose now joe and donald athome are the only ones that have made commits (git),
then the log in the redmine site will show:
donald there instead of donald athome
as donald is looked up, and replaced by donald there