We want to use the same user-id across all our dev tools, but this limitation from subversion is not allowing us to use email addresses as usernames.
Well, since you can create groups consisting of multiple users, and later refer to them by using #<groupname>, I guess having a # in a regular username may be a problem.
This is from the example in the default authz file generated when creating new svn repository:
[groups]
harry_and_sally = harry,sally
[repository:/baz/fuz]
#harry_and_sally = rw
Which gives the users in group harry_and_sally read and write permissions to the repository in /baz/fuz.
It really depends on how you set up Subversion. It's possible that the standard Subversion built-in authentication for svnserve does not allow . and # (I haven't tried). I have set up my Subversion repositories using Apache instead of the built-in svnserve. Under Apache you can use standard Apache access controls like htpasswd files or even integration with LDAP or Microsoft Active Directory. Then you can use e-mail addresses or AD logins for your Subversion users.
Subversion actually uses UTF-8 internally to store all of its data, including the usernames, so there isn't really any restriction on what you can name your users. For example, I just created a commit with the user:
'Й, ק, م, ๗, あ, 叶, 葉, and 말.'
The thing is, other programs may reserve certain characters for special purposes, such as [, =, and # in the svn passwd file. Subversion can handle a wider range of usernames, but that particular file format cannot. If you are finding yourself unable to use certain characters, it is a limitation of some other link in the chain, like Apache or your IDE or your database, or whatever.
That isn't too helpful because you probably can't easily fix whatever is causing this or switch tools, but such is the state of "weird" characters these days.
It does allow "." in username, never tried #.
At my $JOB company e-mail address is the standard user name for Subversion, so it must work.
On my team, however, we insisted on being given our (also company-wide) Windows user names which tend to be no longer than 8 characters. User names like Reallylongfirst.Andlastname#amazing-products.com make for terrible usability in standard GUI log viewers and don't play nicely with svn blame.
The usual way to construct URIs containing a username is
protocol://user#host:port/path. svn uses this too, so the # character is special. I haven't tried but I'm rather confident that you could escape it (like %40) to make it work. However, IMO it's a rather bad idea to use complete email addresses as usernames. If you're inside a company, why can't you use the local part? Everything else will most likely be the same for all users, thus you're only repeating information -- and it won't play nicely with log views.
See also RFC 3986.
Related
I have this in my .install4j file:
<mediaSets>
<windows ...
mediaFileName="${compiler:product.name} ${compiler:edition.name} Win32 ${compiler:sys.version}" ...>
<mediaSets>
The issue is with the name of the generated media file.
I get: Our-Product_Enterprise_Win32_6.0.36-SNAPSHOT.exe
I want: Our-Product Enterprise Win32 6.0.36-SNAPSHOT.exe
I switched off the "Convert dots to underscores" setting, which helped clean up the version number, but how do I prevent Install4J from replacing all blanks with underscores?
I could live with using some other character, but:
_ (underscore) is confusing since the name already has dashes in it (it should be possible to read out a name over the telephone).
- (dash) is even more confusing since there are more dashes in it.
~ (tilde) looks weird - the installer is seen by non-tech people, and I don't want to confuse them.
en-space and em-space might work, but could cause character set weirdness, particularly since we're building Linux and Windows installers (and maybe Mac installers in the future). I.e. I'll want to stick with ASCII-7 if at all possible.
Currently this is not possible. For 8.0.3, I have now implemented an option "Convert spaces to underscores" so you can disable the replacement.
Please contact support#ej-technologies.com to get a build where this is already implemented.
First post!
This is an issue ive come across recently when an LDAP aware application that shall remain nameless is reporting an error in a DN in one of the 19 Domains in the forest but the vendor cant give me any further detail around what the object with the error is other than "We are pretty tight on RFC compliance so it could be anything and we see error 34"
Helpful right.
My other LDAP aware apps are perfectly fine so this is more of a "prove you wrong" type of exercise.
I have a list of DNs exported from every object that has changed in the last 10 days from every domain.
9 days ago is when the thing broke so would capture everything that they are trying to say it would be.
What im hoping to find out is if there is a way for me to run a PS script to check for RFC complaince in the DN string?
I have no ides whats involved with RFC, cant even find a clear explanation of what is and is not accepted.
Anyone have any pointers?
This is just a guess, but it's something that's burned me before: Do you have any accounts with forward slashes in their name? Even Microsoft's own code has problems with that.
The DN would look something like:
CN=test/user,OU=Users,DC=domain,DC=com
That's perfectly valid (at least AD allows it). But if you try to bind to that directly via LDAP, and you just drop it into an LDAP path, you get this:
LDAP://CN=test/user,OU=Users,DC=domain,DC=com
However, in an LDAP path, forward slashes are special characters, so it sees the path as just LDAP://CN=test, which of course won't work. The slash must be escaped (just replace / with \/):
LDAP://CN=test\/user,OU=Users,DC=domain,DC=com
To find out if you have any accounts with slashes in their name, you can do a query like this:
(&(objectClass=user)(cn=*/*))
In PowerShell, you could do that like this:
Get-ADUser -LDAPFilter "(cn=*/*)"
This could also happen if you have any OU's with slashes in their name.
I want to allow emails like myusername+something#mydomain.com instead of simply myusername#mydomain.com using Zimbra - this is a feature on Gmail.
Does anyone where to begin looking to allow this to work? Postfix?
How to implement this in Zimbra is available on the official Zimbra wiki here:
http://wiki.zimbra.com/wiki/Plus_Addressing
Zimbra stores a lot of Postfix parameters in LDAP so modifying the running Postfix config won't work.
To enable Plus Addressing with Zimbra, use zmprov as follows:
zmprov mcf zimbraMtaRecipientDelimiter +
Note that the delimiter can be a character other than '+'.
To disable Plus Addressing, use zmprov as follows:
zmprov mcf -- -zimbraMtaRecipientDelimiter +
After making changes to enable or disable this feature, it may be required to restart tomcat. Postfix should pick up the changes automatically, though it may take a couple minutes to register.
Yeah, postfix is the right place. Look at recipient_delimiter in the postconf docs:
recipient_delimiter (default: empty)
The separator between user names and address extensions (user+foo). See canonical(5), local(8), relocated(5) and virtual(5) for the effects this has on aliases, canonical, virtual, relocated and on .forward file lookups. Basically, the software tries user+foo and .forward+foo before trying user and .forward.
Example:
recipient_delimiter = +
At least two brilliant programmers, Linus Torvalds and Guido von Rossum, disparage the practice of putting keywords into a file that expand to show the version number, last author, etc.
I know how keyword differences clutter up diffs. One of the reasons I like SlickEdit's DiffZilla is because it can be set to skip leading comments.
However, I have vivid memories of team-programming where we had four versions of a file (two different releases, a customer one-off, and the development version) all open for patching at the same time, and was quite helpful to verify with a glance that each time we navigated to an included header we got the proper one, and each time we pasted code the source and destination were what we expected.
There is also the where-did-this-file-come-from problem that arises when a hasty developer copies a file from one place to another using the file system, rather than checking it out of the repository using the tool; or, more defensibly, when files under control in locations A, B, and C need to be marshalled (with cherry-picking) into a distribution location D.
In places where VCS keywords are banned, how do you cope?
I've never used VCS keywords in my entire career, over 30 years. From the most primitive VCS system I've used, up to the present (TFS), I've used some other structure to understand "where I am".
I am rarely in a situation where I've only got one file to work with. I've usually got all the other files necessary to build the project or set of projects. I usually use branching (or streams on one occasion), and I'm working on some slice of the given branch or stream.
If I'm working on multiple branches or streams, I'll have one directory tree for each. All I need to do to know what file I'm working on is check the file path, at the very worst.
At the very best, the version control system will tell you exactly which version of the file you're working on, what the change history is, who else is working on different versions of the file, and anything else you'd care to know.
This doesn't exactly answer your question, but I imagine Linus and Guido have reasons for disliking keywords that don't apply to small-team corporate development.
An $Id$ tag for instance, has what you could consider to be a global version number. Linux and I guess also Python development is fragmented enough that no number can be global. Lots of people have their own repositories all over the place that would fill in their own $Id$ values and then those patches might be sent to Linus or Guido's repositories where they don't make any sense.
However, in your environment, you probably have one central repository which would assign these and it would be fine. Sounds like you're using git. I wonder if it's possible to configure the central git repository to do tag substitution while the local developer repositories don't. Or perhaps it's better to get the commit hash in the tag.
My hosting company says it is possible to fill an HTML form text input field with just the right amount of garbage bytes to cause a buffer overflow/resource problem when used with Apache/HTTP POST to a CGI-Bin Perl script (such as NMS FormMail).
They say a core dump occurs at which point an arbitrary script (stored as part of the input field text) can be run on the server which can compromise the site. They say this isn't something they can protect against in their Apache/Perl configuration—that it's up to the Perl script to prevent this by limiting number of characters in the posted fields. But it seems like the core dump could occur before the script can limit field sizes.
This type of contact form and method is in wide use by thousands of sites, so I'm wondering if what they say is true. Can you security experts out there enlighten me—is this true? I'm also wondering if the same thing can happen with a PHP script. What do you recommend for a safe site contact script/method?
I am not sure about the buffer overflow, but in any case it can't hurt to limit the POST size anyway. Just add the following on top of your script:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 100; # max 100K posts
$CGI::DISABLE_UPLOADS = 1; # no uploads
Ask them to provide you with a specific reference to the vulnerability. I am sure there are versions of Apache where it is possible to cause buffer overflows by specially crafted POST requests, but I don't know any specific to NMS FormMail.
You definitely should ask for specifics from your hosting company. There are a lot of unrelated statements in there.
A "buffer overflow" and a "resource problem" are completely different things. A buffer overflow suggests that you will crash perl or mod_perl or httpd themselves. If this is the case, then there is a bug in one of these components, and they should reference the bug in question and provide a timeline for when they will be applying the security update. Such a bug would certainly make Bugtraq.
A resource problem on the other hand, is a completely different thing. If I send you many megabytes in my POST, then I could eat an arbitrary amount of memory. This is resolvable by configuring the LimitRequestBody directive in httpd.conf. The default is unlimited. This has to be set by the hosting provider.
They say a core dump occurs at which point an arbitrary script (stored as part of the input field text) can be run on the server which can compromise the site. They say this isn't something they can protect against in their Apache/Perl configuration—that it's up to the Perl script to prevent this by limiting number of characters in the posted fields. But it seems like the core dump could occur before the script can limit field sizes.
Again, if this is creating a core dump in httpd (or mod_perl), then it represents a bug in httpd (or mod_perl). Perl's dynamic and garbage-collected memory management is not subject to buffer overflows or bad pointers in principle. This is not to say that a bug in perl itself cannot cause this, just that the perl language itself does not have the language features required to cause core dumps this way.
By the time your script has access to the data, it is far too late to prevent any of the things described here. Your script of course has its own security concerns, and there are many ways to trick perl scripts into running arbitrary commands. There just aren't many ways to get them to jump to arbitrary memory locations in the way that's being described here.
Formail has been vulnerable to such in the past so I believe your ISP was using this to illustrate. Bad practices in any perl script could lead to such woe.
I recommend ensuring the perl script verifies all user input if possible. Otherwise only use trusted scripts and ensure you keep them updated.