Production scripts: sign me up for obfuscation

01 January 2010 | general | Tags: , ,

If there’s one thing that will always make me angry, it’s people that should not be editing my code going and editing my code. If you want to change something on the server and you have sudo privileges please let the real admin know beforehand. I don’t mind people improving processes or scripts but if said user was in my shoes – they’d want to know about changes if they were the one getting called at 3am to fix things. This goes for stored procedures, triggers, views, and anything in production.

I’m all for non-obfuscation in opensource code that allows it to be audited and tested and improved, or code that can be kept secure in production. However, some clients require admin/sudo privileges on their servers even if that server is a managed server, oddly written SLAs sometimes allow this. So, if that is the case and you find scripts being changed without your prior knowledge – try obfuscation and see how well it works.


5 Responses to “Production scripts: sign me up for obfuscation”

  • 1 paul Says:

    Well the real problem is there is no change control process in your systems, you need to implement one to avoid the things your complaining about! Hence take responsibility rather than pass blame!

  • 2 Brian Harring Says:

    Personally I prefer to just revoke the devs who pulled that crap if I’m the SA.

    Either way, yeah, quite possibly one of the worst things about system maintenance is when others have their fingers in the pie and don’t understand the notion of production…

  • 3 themattreid Says:

    @paul

    Actually we do have change control processes, the problem is clients that do not respect the change control process and violate the procedures. Obfuscation is a preventative measure to ensure that people that might violate the procedure are prevented from doing so through code measures such as this. Likewise, compiled programs are less likely to be messed with unless someone goes and recompiles the app and then uploads it to the server – but in scripting languages that do not use obfuscation the code is open to editing for users that have access and do not adhere to the usage policy. A SE/SA/sudo-user cowboying around on the system needs to be fired IMHO but at least you can prevent these kinds of actions through obfuscation.

  • 4 Toby Says:

    April 1 is still 3 months away.

  • 5 themattreid Says:

    I take it obfuscation is not something you are interested in. Perhaps you would like to give some reasons for thinking this is a joke since your current comment did not offer any constructive criticism?