good software practices frederick luehring [email protected] indiana university summer student...

15
Good Software Practices Frederick Luehring [email protected] Indiana University Summer Student Meeting Wednesday June 3, 2015

Upload: logan-lloyd

Post on 03-Jan-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Frederick Luehring

[email protected]

Indiana University

Summer Student Meeting

Wednesday June 3, 2015

Page 2: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Concepts • Backups – one can never have too many backups• Code versioning – be able to see what changed• The history stack and login files• Passwords, Certificates – longer is better

– How encryption differs from a password

• Privacy / Information Protection– If you put information on any public social media it will never

go away.

• Integrated Development Environments (IDEs)– Not for everyone

• Valgrind – your friend for chasing the dread memory leak

June 3, 2015 F. Luehring Pg. 2

Page 3: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Backups• I strongly recommend something like the Apple Time

Machine that backs up continuously.– This is your best defense against unintended file deletes.– There are cloud-based tools that do this same functionality

like CrashPlan by Code42.• Encrypt any backup if you store in the cloud.

• One can also use tools like DropBox and Box (supplied by IU at no cost) but this requires remembering to do it. Thom Sulanke runs the amanda system for machines in Swain Hall.

• There not a hard drive ever made that will not fail eventually. You should plan accordingly.– Having some backups off site so that your data is safe in the

case of a fire, tornado, flood or similar is essential.June 3, 2015 F. Luehring Pg. 3

Page 4: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Code Versioning• There are many tools for doing this including:

– SVN– Git

• All versioning tools allow you to save versions of your code as you go along and give them names (tags).– For example TRT_Digitization-01-00-24

• All versioning tool provide flexible means to understand the differences between tags– Useful in understanding unintended side effect of changes.

• ATLAS has a very strict information protection policy so DO NOT PUT physics analysis code into GitHub or other public repositories.

June 3, 2015 F. Luehring Pg. 4

Page 5: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Code Versioning• If you work on ATLAS you should put your code in a

personal ATLAS SVN repository.– The instructions for using SVN can be found in the ATLAS

Software Development Workbook:– https://twiki.cern.ch/twiki/bin/view/AtlasComputing/

SoftwareDevelopmentWorkBookSVN– SVN is also very use full storing text files like LaTeX,

shell/Perl/Python scripts, web page html, PDF, PS, etc.– Do not put binary or executable files in SVN as SVN is

designed to work with text files and you can cause trouble with the SVN server if you put big binary files into SVN.

June 3, 2015 F. Luehring Pg. 5

Page 6: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

UNIX History Stack & Login Files• You should set your account up to preserve a large

history of your commands (10,000 or more).– Decide whether you want the commands written immediately

as you enter them or when you end/exit each session.• Immediate writing is safer as it saves the commands even if the computer

crashes but it mixes commands from multiple windows.• Writing at the end loses the history if you fail to exit the session cleanly

but separates the sessions in the history file.

• Spend a little time understand the login/logout files:– .bash_login, .bash_profile, .bashrc bash– .login, .logout, .tcshrc tcsh– .zlogin, .zlogout, .zshrc zsh– .emacs emacs editor– .vimrc vim (vi) editor– rootlogon root

June 3, 2015 F. Luehring Pg. 6

Page 7: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Authentication• Authentication is most familiar to you as entering a

password to access a system.– Modern OSs use a hashing algorithm in conjunction with a

salt (don’t ask) to convert your password into a number called a hash.

– It is not possible directly invert the hashed password to get back the original password even with access to the hashed password and the hashing algorithm source code.

– A user authenticates and is granted access by giving the clear text password and having the system calculate the hash and check that the hash matches the stored value.

– Hashing is also useful for checking that a file transfers correctly without being changed.

June 3, 2015 F. Luehring Pg. 7

Page 8: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Encryption• Encryption is harder to implement then simple

authorization because whatever information has been encrypted must be recoverable.– The keys used to encrypt information are huge: typically

thousands of bits and generated by a program.– One of the most common types of encryption is called public

key encryption (PKI) where a user gives someone wanting to send them a message a public key with which the user can encrypt the message (but not decrypt the message). The user has a well guarded private key which is used to decrypt the message.

– In all encryption methods one must protect the key that can be used to decrypt the message – if an attacker gets the key the game is over. Typically a 20 or more character passphrase is used to encrypt the key.

June 3, 2015 F. Luehring Pg. 8

Page 9: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Best Practices Passwords• Passwords should be long but memorable.• Using something close to what would be a simple

phrase is generally OK as long as you don’t do things in a way that would allow an attacker to try combinations of a few common words.

• You should have a different password for all of your important accounts (especially those can be used to buy things and that contain personally identifiable information like photos, financial records, etc.).

• It is safest to use an encrypted file system or password management utility to hold your passwords. – This is especially true for passwords that are needed

decrypt data as there is typically no way to get the data back if you forget the password used to encrypt the keys.June 3, 2015 F. Luehring Pg. 9

Page 10: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Best Practices• Never share your password with anyone.

– Don’t do it. Just don’t.

• Never write down your password.– If you use some sort of a password manager you really only

need to remember your password.– The one exception to this is to provide to a coworker and/or

family member, the password needed to access your other passwords in the encrypted file system or password utility that you are storing your passwords in.

• I recommend putting that password in a sealed envelope in a safe which prevents it from falling into the hands of online hackers.

• Change your password periodically and of course anytime you think that it may have been revealed.

June 3, 2015 F. Luehring Pg. 10

Page 11: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Changing/Creating Passwords• Here is a simple safe way to create a new password

or passphrase.– Enter but do not save your new password in a text editor

window.– Copy and paste the password into application used to

create/change the password.– Also paste the password into the system you for managing

passwords.– When done close without saving the editing session and

also copy something else to overwrite password in the system cut/copy/paste buffer.

June 3, 2015 F. Luehring Pg. 11

Page 12: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Grid and SSH Certificates• You will have at least two PKI encryption certificates:

– Your ssh certificate is usually stored in the hidden ${HOME}/.ssh directory with the name id_rsa or id_dsa and with a public key named id_rsa.pub and id_dsa.pub.

• This certificate is typically generated by ssh-keygen.• It is safest to use passwordless logins whenever possible.

– Your Open Science Grid (OSG) grid certificate is stored in the hidden ${HOME}/.globus directory and in your browser.

• CERN also issues grid certificates which can be used for authenticating on web pages.

– Some people also use gpg certificates and Enigmail to send encrypted mail.

• All certificates are small files that are held in an encrypted format and are decrypted by a passphrase.– The serve to identify you and you cannot ever share them.

June 3, 2015 F. Luehring Pg. 12

Page 13: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Privacy / Information Protection• Be careful with everything – the web remembers it all.

– Your grandchildren will find those humorous party photos...

• More specifically ATLAS has very strict rules about what can be disclosed publically.– Almost all information to be published publically must go

through a soul-sucking, heavyweight approval process so no you cannot put the plots you made this afternoon on your Facebook page.

– There are some exceptions for students presenting at regional and national meetings that reduce this load.

– There are many pages of plots that are approved for public consumption – you can use these plots anywhere including social media.

– If you have any questions ask...

June 3, 2015 F. Luehring Pg. 13

Page 14: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Useful Software Tools• Some useful but hard learn tools are:

– Eclipse an integrated development environment (IDE)– Valgrind for chasing memory leaks.

June 3, 2015 F. Luehring Pg. 14

Page 15: Good Software Practices Frederick Luehring luehring@indiana.edu Indiana University Summer Student Meeting Wednesday June 3, 2015

Good Software Practices

Final Thoughts• If you have questions ask – many people have done

what you are doing.– Feel free to use the iu-atlas/iu-trt mailing list

• It is less work to be careful choosing good passwords and keeping all software (especially any software used on Microsoft Windows) up to date than to recover from a security breech. Apply all patches for:– Adobe Acrobat, Creative Suite, Flash– Apple OS X, Keynote, Numbers– Linux– Microsoft Office, Windows– Oracle Java (Use version 8 and not version 6 or 7)

• Always use the built-in firewall on all systems.

June 3, 2015 F. Luehring Pg. 15