I've never used the checksum when downloading various executables or zip files from the Internet. I know it is used to check for consistency and add a bit of security. But is it necessary for when you download from a respectable project like Apache or Microsoft. How many of us actually use the checksums or hashcodes to verify the contents?
FYI, please let me know if I have strayed too far from StackOverflow's acceptable content.
When downloading files where integrity is critical (an iso of a linux distribution for example) i tend to md5sum the download just in case.
The source may be trusted, but you never know when your own NIC's hardware may start to malfunction.
Another use is to verify that a file that you already have is the same (i.e. unaltered, uncorrupted and as current) as the file available for download from the trusted source.
This might occur if
You have previously downloaded the file
You got the file from another site
You got the file from a network share
Someone gave you the file on a CD / flash drive / etc
You used some other method of avoiding a potentially long download
This is so that you can check the integrity of the file. I use it all the time. You basically just run some program that will produce a MD5 checksum, or whatever hashing method is used, on the file and see if the two checksums match. If not, then the files are different. However, note, that it is possible to have two files that yield the same checksum, but the likelihood you will run into this comparing two files of the same size is pretty low, unless you are contriving the example.
This is very useful. I found a bug in a CD burning program recently; I kept having a problem with a particular file on a particular computer. I finally just compared the checksums of the file from the CD and the one on the original computer, they were different, and I was able to solve the problem!
Imho it's only useful if you have downloaded a large file and want to check if it's corrupted before re downloading it (i.e. if application is not installing correctly).
To be sure that the file you download is the good one file and no other modified by some others with malicious intentions. As this information in Apache says:
"Any attacker can create a public key and upload it to the public key servers. They can then create a malicious release signed by this fake key. Then, if you tried to verify the signature of this corrupt release, it would succeed because the key was not the 'real' key. Therefore, you need to validate the authenticity of this key."
To verify you can follow the steps here.
Although you are choosing to download from a trusted source (e.g. Apache.org) your download request will likely be served by a mirror site. The trusted site in question does have the resources to serve all requests so mirrors serve a valuable function. However, the trusted site does not necessarily have full control over the mirror site and it's possible that the mirror's owner (or a third party) could replace the mirrored executable with malicious code. By verifying the trusted source's hash against the downloaded file you insure that it has not changed in transit (for whatever reason.)
It's used for both integrity reasons (particularly on ftp sites, where you may have mistakenly downloaded in ascii mode). Additionally, it can be used to verify the download has not been altered, assuming you download from location a and get checksum from location b (often download is from mirror, and hash from official site).
For integrity purposes, though, signing a file is going to be more useful than just hashing it.
I use MacPorts on Mac OS X, which is a source based package manager; each Portfile contains a description of how to download, patch, compile, and install a piece of software on Mac OS X. Included in the Portfile is the checksum of the particular version of the tarball to download. This helps ensure the integrity of the file from many possible problems; sometimes, people will update a tarball without incrementing the version number, which may cause patches to fail to apply or the code to break under certain conditions, or sometime the package may become corrupted, or an attacker may be tampering with the software in the hopes that you will install it.
So, I will have to say that yes, I use the checksums every time I install software (though my package manager does it automatically for me, I don't do it directly). And even if you are downloading manually from a respectable project, you many wish to download the code itself from a faster, closer mirror, and then verify the checksum against a copy downloaded from the more trusted master server; that helps keep it more difficult to attack as multiple servers would have to be compromised rather than just one mirror.
Related
Is there any possibility to encrypt an ASAR package so that possibly malicious actors cannot reverse-engineer my application in virtually no time? So far, I have not found any information on this whatsoever.
In short: no.
Javascript cannot be complied or protected. If your Electron Application is on another computer the source code (or at lest the parts that do not lie on a server) are open to the user.
Can anyone suggest me the steps to apply patch (patch upgrade) on IBM Informix database. Please suggest the best practices available. If possible share me the URL or any documents.
It's a big topic. A good deal depends on how the server is currently set up — there are setups that make it hard and others that make it easier. Another major factor is your level of risk averseness. You need to make an assessment of the amount of down-time you can afford. Also, how often have you practiced recovery from backups — it probably won't be necessary, but you need to cover your bases.
I am assuming you're using Informix Dynamic Server, not Informix Standard Engine (SE). Upgrading SE is much, much simpler.
Preparation
Before you install, make sure you have a good, recent, level 0 archive of your system.
Also, make sure you know where your software is installed, and which disks and files it uses.
Route 1: Simple, but potentially risky
Make sure you have a backup copy of $INFORMIXDIR.
Take down the servers that are currently running using this $INFORMIXDIR.
Install the new version of the software over the existing software.
Restart the server
Why is this risky? At issue is what happens if anything goes wrong, and also the length of time the server(s) is (are) down. If you bring up the server and decide something is wrong and you wish to go back to the old version, you have to take servers down, reinstall the old software (copy off the backup?), and then bring the (old version of the) server back up. This takes time. This isn't often a problem, but it has happened on occasion over the last couple of decades.
Route 2: Parallel install
This is the way I do it, but I ensure that my system is set up so that this is easy to do. In particular, the file names used to identify the chunks used by the server are symlinks to the actual storage. This makes it easier to move or replace storage when necessary — you change the symlink instead of having to modify the server configuration.
Create a new directory (e.g. /opt/informix.new) and install the new version of the software in it.
Copy the configuration files from the current $INFORMIXDIR (e.g. /opt/informix) into the new one.
Ensure any other files or directories under the old $INFORMIXDIR that are needed for the new one are copied across or recreated empty.
Review the parallel setup; as best you can, make sure that when you're ready to switch, everything will work.
Take the old server down.
Move the old $INFORMIXDIR to a new name (i.e. mv /opt/informix /opt/informix.old).
Move the new $INFORMIXDIR to the working name (i.e. mv /opt/informix.new /opt/informix).
Restart the server
Why is this less risky? The primary advantage is that the old software is still on the machine and switching back to the old version is therefore simply a question of undoing the original pair of move commands. Another major advantage is that the down-time for the system is limited to the time taken to stop, switch directories, and restart the system.
What are the potential downsides? If you weren't careful enough about copying the necessary files from the old to the new system, you can find yourself missing something critical.
Note that if your chunks are not symlinks, and especially if they are cooked files stored under the old $INFORMIXDIR, you can run into problems. These are not insuperable; you just have more work to do than simply moving directories. Do not (repeat not) move or copy chunks while the server is running. They will not (necessarily) be consistent.
Variations? I usually needed multiple versions of Informix around, so I'd use sets of directories like /work3/informix/ids-12.10.FC1 and /work3/informix/ids-11.70.FC4 as the real directories. I'd then use a standard symlink name as $INFORMIXDIR, such as /opt/informix which would link to the current version-specific INFORMIXDIR under /work3/informix in this example. (Actually, there were some extra levels of complexity in my setups, but my requirements as an Informix developer were different from those of most customers.). But the key point is that instead of moving directories, I switched a symlink — rm /opt/informix; ln -s /work4/informix/ids-12.10.FC3 /opt/informix to use 12.10.FC3 instead of 12.10.FC1, for example.
Post-installation
Run a new level 0 archive.
General observations
Informix upgrades are usually seamless and smooth. If there is conversion work to do on the upgrade, the server does it automatically when the new version is brought up.
Be aware of the mechanisms for reverting to an older version of the server if that is found to be necessary.
I've done presentations and/or papers on this in years past at IIUG conferences. Check out the IIUG web site, and the IBM Informix documentation.
We outsourced the development of Blackberry 5, 6, and 7 apps. Please bare in mind that I have absolutely no knowledge of Blackberry development at all.
Development is complete, and they have sent us the source code - a collection of .cod, .csl, .cso, .debug, .jad and .rapc files.
I would at least like to review the code in terms of it's consistency and standards - somewhat a measure of the quality. Clean code is not something specific to any one platform.
I have tried to open each of these files in notepad, but with no source code found.
Please advise me on what I need before I go pay them a visit.
The files you have been given are the files that are created as part of the build of your project and the resultant executable files. There is no source included here.
In a BB OS Build, regardless of the development environment used, the Java source files will all have the suffix .java, and the assets (images etc.) will have a suffix appropriate to the asset (like .png). If you don't see these file suffixes, then you have not been given the actual source. You should be able to view the java files using Notepad, the other files will open in an appropriate application (like paint).
To get the complete source, you should just ask the full 'project' files for your development. This will be a directory with a number of sub directories. The actual names used and the structure will depend on the development tool. If your developer is using Eclipse, then the two important directories are called src for source and res (resources) for the assets. If they are using another development environment, then the directories might have different names. So you should ask them what development environment they are using too.
Two other points:
1) If you are paying for this development and wish to review the code, but are not familiar with Java, then I would recommend that you pay someone to review the code who has knowledge of BB Java. There are two reasons for this:
(a) you will not be able to form a judgement on the appropriateness of the code without some understanding of Java, and
(b) you will not understand if the correct BB Java approaches have been used.
You need to be cautious about this, because programmers will always find fault in other developer's code. The question is how significant the faults are.
2) Some developers might be wary of giving source to their client while some payment is outstanding.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been thinking of rolling my own code for enabling my Delphi application to update seamlessly as I'll be going for "release often, release early" mentality furthermore. There are various Delphi solutions (both freeware and paid) out there and I'd like to ask if you've been using any of them or simply went on with your own solutions in this area. Any comments on the auto-update topic are welcome.
What ever scheme you use, it may be handy to know that you can actually rename a running .exe file. So rename file, copy in new file works nice. And the next time someone launch the program they will launch a the new version. This is ofcourse very handy in enviroment where many users run the same .exe file, like in citrix/terminal server/network share cases.
Years ago I wrote a simple tool which is started instead of the real program, checks for updates, loads and installs them (if any are available), and finally starts the real application.
There are however problems with that approach if your program works in a properly administered environment, where users normally don't have write access to the program directories. You can no longer simply update your own program in such environments. That's why a lot of programs these days come with their own updater tool, which can be installed to run with elevated permissions, so that program updates can be applied even though only standard users do ever log on to the system.
You have to decide whether your target audience can be assumed to run on power user or administrator accounts, or whether you will have to deal with above-mentioned problems. With Vista things got considerably harder already.
With all these problems (net access over proxies, missing write permissions for installation directories, the need to update files that the updater itself is using - just to name a few) I wouldn't try again to code this on my own. Much better to check if any one of the available solutions does all you need it to.
I use the Synapse routines GetHTTP to return a specific resource, and if found then check against the local system to see if an update is required. If so then the resource tells me what page to go to launch and I throw the URL into shell execute so the users
preferred browser is displayed.
Most of the time the download is a setup program created by InnoSetup which updates the users system and database to the latest version. When a new "paid" upgrade is needed, I then send the user to a "purchase upgrade" form. My web resources are ASP pages, so I can redirect to a different resource based on the customers version number.
For the main application (our application has a server piece, and a client piece) I have a loader which will check the server to see if the version of the client file on the server is different than the version on the client...if so, it prompts the user if the user wants to update/revert. We chose to prompt the user as sometimes an accidental bug might make it into the system and the user has to downgrade/upgrade only specific machines to help troubleshoot. I maintain a database record with the minimum version required which is updated via the database patch, so if a version must be retired then the record is updated accordingly.
I created my own solution too based on Indy for downloading and http://sourceforge.net/projects/makeupdate/ for file patching.
Before that I have used and tried several commercial tools, but no one was doing exactly what I needed.
I use TmxWebUpdate. It's free, simple and gives you good control over the process. I actually own TMS Component Pack with TWebUpdate but never really found a good reason to switch.
Edit: Link updated
We rolled our own as well. Its really not too difficult.
Our process goes something like:
When the main app is launched, it checks (using funcs from the synapse library) if there's an update available (assuming its configured to check, of course).
If so, it notifies the user and askes if they want to update.
If they do, it launches an updater .exe, and closes the main app.
The updater exe downloads the new files based on the contents of a text file it retrieves, keepiing the files in memory.
When the updater is done downloading everything correctly, it then saves the downloaded files to disk, backing up any files it replaces. This way if the download gets interupted, you dont end up with half the files installed.
Finally, it launches the main app again, and closes itself.
The trick w/ Vista is that you need to have an entry in the updater program's manifest to force it to run with administrator rights.
Normally we use the third party tool. But in some situations it was not usable so I created an own solution, which was pretty standard:
Get xml (or any other format) with update info.
If newer files are published, download and install them.
I use TWebUpdate . It works ok and has a ton of interesting options, but documentation isn't so great and I did bump into a few problems - which is why I download a full installer, instead of just the files...
I will be keeping an eye on this question, btw...
We use our own solution which follows these steps:
Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
If newer version available, app downloads compressed binary package to exe location.
When download is finished, user is asked to restart application.
Upon start, application checks for presence of update package
App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
When finished, app executes new exe and closes itself.
No additional updater needed, the app exe can handle it all by itself.
For the compressed package we use our own update builder.
The package contains an index of files with a file hash, destination folder (relative path to main exe) and the compressed files.
During update we compare the stored hash with the extracted file to detect corupted files.
With Vista I see two solutions to enable Standard User Accounts to actually update the applications files:
Configure your setup to change permissions of the programs installation directory. This way files in "C:\Program Files (x86)\Your Company\You App" can be modified on Accounts with limited rights.
Example code for InnoSetup would be:
[Dirs]
Name: "{app}"; Permissions: users-modify
Install files that you plan to update to the ProgramData folder instead of the user defined directory and use this directory as an override folder. If files exist in ProgramData, use those, else check in install dir.
InnoSetup code:
[Files]
Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\";
Same as "stg" and "GuyWithDogs", I'm using TWebUpdate from TMS. Although the documentation isn't so great, Its not so difficult to learnt.
With TWebUpdate, you have some options what the protocol you use, it could be done via HTTP, FTP or network access.
For communication layer, TWebUpdate uses WinInet. In some machines, the windows / IE URL cache can be frustating, so I've added a routine to clear the auto-update server address from cache first to ensure the information gathered from the server is up-to-date.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been thinking of rolling my own code for enabling my Delphi application to update seamlessly as I'll be going for "release often, release early" mentality furthermore. There are various Delphi solutions (both freeware and paid) out there and I'd like to ask if you've been using any of them or simply went on with your own solutions in this area. Any comments on the auto-update topic are welcome.
What ever scheme you use, it may be handy to know that you can actually rename a running .exe file. So rename file, copy in new file works nice. And the next time someone launch the program they will launch a the new version. This is ofcourse very handy in enviroment where many users run the same .exe file, like in citrix/terminal server/network share cases.
Years ago I wrote a simple tool which is started instead of the real program, checks for updates, loads and installs them (if any are available), and finally starts the real application.
There are however problems with that approach if your program works in a properly administered environment, where users normally don't have write access to the program directories. You can no longer simply update your own program in such environments. That's why a lot of programs these days come with their own updater tool, which can be installed to run with elevated permissions, so that program updates can be applied even though only standard users do ever log on to the system.
You have to decide whether your target audience can be assumed to run on power user or administrator accounts, or whether you will have to deal with above-mentioned problems. With Vista things got considerably harder already.
With all these problems (net access over proxies, missing write permissions for installation directories, the need to update files that the updater itself is using - just to name a few) I wouldn't try again to code this on my own. Much better to check if any one of the available solutions does all you need it to.
I use the Synapse routines GetHTTP to return a specific resource, and if found then check against the local system to see if an update is required. If so then the resource tells me what page to go to launch and I throw the URL into shell execute so the users
preferred browser is displayed.
Most of the time the download is a setup program created by InnoSetup which updates the users system and database to the latest version. When a new "paid" upgrade is needed, I then send the user to a "purchase upgrade" form. My web resources are ASP pages, so I can redirect to a different resource based on the customers version number.
For the main application (our application has a server piece, and a client piece) I have a loader which will check the server to see if the version of the client file on the server is different than the version on the client...if so, it prompts the user if the user wants to update/revert. We chose to prompt the user as sometimes an accidental bug might make it into the system and the user has to downgrade/upgrade only specific machines to help troubleshoot. I maintain a database record with the minimum version required which is updated via the database patch, so if a version must be retired then the record is updated accordingly.
I created my own solution too based on Indy for downloading and http://sourceforge.net/projects/makeupdate/ for file patching.
Before that I have used and tried several commercial tools, but no one was doing exactly what I needed.
I use TmxWebUpdate. It's free, simple and gives you good control over the process. I actually own TMS Component Pack with TWebUpdate but never really found a good reason to switch.
Edit: Link updated
We rolled our own as well. Its really not too difficult.
Our process goes something like:
When the main app is launched, it checks (using funcs from the synapse library) if there's an update available (assuming its configured to check, of course).
If so, it notifies the user and askes if they want to update.
If they do, it launches an updater .exe, and closes the main app.
The updater exe downloads the new files based on the contents of a text file it retrieves, keepiing the files in memory.
When the updater is done downloading everything correctly, it then saves the downloaded files to disk, backing up any files it replaces. This way if the download gets interupted, you dont end up with half the files installed.
Finally, it launches the main app again, and closes itself.
The trick w/ Vista is that you need to have an entry in the updater program's manifest to force it to run with administrator rights.
Normally we use the third party tool. But in some situations it was not usable so I created an own solution, which was pretty standard:
Get xml (or any other format) with update info.
If newer files are published, download and install them.
I use TWebUpdate . It works ok and has a ton of interesting options, but documentation isn't so great and I did bump into a few problems - which is why I download a full installer, instead of just the files...
I will be keeping an eye on this question, btw...
We use our own solution which follows these steps:
Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
If newer version available, app downloads compressed binary package to exe location.
When download is finished, user is asked to restart application.
Upon start, application checks for presence of update package
App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
When finished, app executes new exe and closes itself.
No additional updater needed, the app exe can handle it all by itself.
For the compressed package we use our own update builder.
The package contains an index of files with a file hash, destination folder (relative path to main exe) and the compressed files.
During update we compare the stored hash with the extracted file to detect corupted files.
With Vista I see two solutions to enable Standard User Accounts to actually update the applications files:
Configure your setup to change permissions of the programs installation directory. This way files in "C:\Program Files (x86)\Your Company\You App" can be modified on Accounts with limited rights.
Example code for InnoSetup would be:
[Dirs]
Name: "{app}"; Permissions: users-modify
Install files that you plan to update to the ProgramData folder instead of the user defined directory and use this directory as an override folder. If files exist in ProgramData, use those, else check in install dir.
InnoSetup code:
[Files]
Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\";
Same as "stg" and "GuyWithDogs", I'm using TWebUpdate from TMS. Although the documentation isn't so great, Its not so difficult to learnt.
With TWebUpdate, you have some options what the protocol you use, it could be done via HTTP, FTP or network access.
For communication layer, TWebUpdate uses WinInet. In some machines, the windows / IE URL cache can be frustating, so I've added a routine to clear the auto-update server address from cache first to ensure the information gathered from the server is up-to-date.