I’ve got one piece of software at work on a Windows server that has some special encoding(?) voodoo with “encrypted” (rather masked/obscured) passwords in the config file that always causes the config to break if I edit (save) them with Notepad++. In all other regards, it’s perfect and a solid choice for almost any case where you need an editor for text files.
We had the opposite problem, things edited in notepad would fail miserably once deployed to the target Linux servers. Nowadays git checkout settings on the build servers tend to get rid of those, but I remember it was the one thing that would occasionally explode.
I don’t want to dox myself, so a bit vague: No, in this case something strange is going on. The obfuscated passwords get a prefix before the hex string. Like e.g. Jetty uses “OBF:<obfuscated value>”. If I edit a file in Notepad++ that contains such a string, it displays the prefix as some… strange(probably cyrillic?) characters - that aren’t even in my (or the software vendor’s) local encoding. Sometimes some of the characters in the obfuscated string change as well, but not all.
Most strange is, that the obfuscation command outputs the obfuscated string in a file in my local codepage - and everything is normal in VS Code, in regular Notepad, when printing the file on the command line,… But Notepad++ somehow fucks it up. I still guess that something is in that obfuscated string that either completely breaks Notepad++ or that Notepad++ is the only one correctly interpreting the byte sequence and all other editors are completely oblivious about some specific thing. ¯\_(ツ)_/¯
And no, I already tried converting everything to ASCII only, letting Notepad++ or other editors display non-printable characters, converting everything to UTF-8 (with or w/o BOM),… Maybe I should try a hex dump?!
I’ve got one piece of software at work on a Windows server that has some special encoding(?) voodoo with “encrypted” (rather masked/obscured) passwords in the config file that always causes the config to break if I edit (save) them with Notepad++. In all other regards, it’s perfect and a solid choice for almost any case where you need an editor for text files.
End of Line (EOL) sensitive software perhaps?
We had the opposite problem, things edited in notepad would fail miserably once deployed to the target Linux servers. Nowadays git checkout settings on the build servers tend to get rid of those, but I remember it was the one thing that would occasionally explode.
I don’t want to dox myself, so a bit vague: No, in this case something strange is going on. The obfuscated passwords get a prefix before the hex string. Like e.g. Jetty uses “OBF:<obfuscated value>”. If I edit a file in Notepad++ that contains such a string, it displays the prefix as some… strange(probably cyrillic?) characters - that aren’t even in my (or the software vendor’s) local encoding. Sometimes some of the characters in the obfuscated string change as well, but not all.
Most strange is, that the obfuscation command outputs the obfuscated string in a file in my local codepage - and everything is normal in VS Code, in regular Notepad, when printing the file on the command line,… But Notepad++ somehow fucks it up. I still guess that something is in that obfuscated string that either completely breaks Notepad++ or that Notepad++ is the only one correctly interpreting the byte sequence and all other editors are completely oblivious about some specific thing. ¯\_(ツ)_/¯
And no, I already tried converting everything to ASCII only, letting Notepad++ or other editors display non-printable characters, converting everything to UTF-8 (with or w/o BOM),… Maybe I should try a hex dump?!