Correctly distributing a Java application with database - mysql

I have this Java application which uses a MySql Database which I want to distribute. My concern is that, to distribute this application I'll need to make the assumption that the target system has both JRE and MySql Server installed.
Is there any way I could bundle my application with the JRE and the MySql server so that if they aren't already present on the system, my app can install them and then run the application?

No you should not bundle them and deliver them as part of your installation because of licensing.
This applies to both Oracle JRE and MySQL.
Update after #Stephen C comment.
It seems that it is possible to redistribute the JRE provided certain circumstances.It is illadviced though for the reasons that are explained in Stephen C answer. I have seen these issues arise in practice.
End Update
I am not sure what is the "safest" path (safest related to licensing issues).
Perhaps an installer that downloads them on the spot as part of the required components is ok.Friends here can correct me if I am wrong on this

You CAN bundle a JRE with a Java application, provided that you follow certain conditions. (If I recall correctly, this is covered by the standard Sun/Oracle license that you agree to when you download the JRE. I think the phrase is a "binary distribution" or "binary redistribution".)
UPDATE
I just checked, and my memory is correct. See Supplemental License Terms section of "Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX". (Paragraph C is the most directly applicable to your scenario.) And as I said above, conditions apply.
END UPDATE
I don't believe that you are permitted to bundle the free version of MySQL.
Personally, I would recommend AGAINST doing this for Java, because:
It inflates the size of your distributable.
It fills the user's disc with extra copies of the JRE.
It presents a problem if it becomes necessary to patch the bundled JRE that the user has (unwittingly) installed.
You are making it difficult for the (sophisticated) user to choose which version of Java to use.

Related

Visual Studio 2019 SSIS-Extension log4j files

Due to the recent problems with log4j I was checking all my code etc..
While doing so i discovered two files named
"slf4j-log4j12-1.7.5.jar" and "log4j-1.2.17.jar"
to find under
"...\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars"
Since we are also developing SSIS packages we kinda rely on this extension.
Sadly I was not able to find anything about SSIS in context with log4j. IMO it's also a bit dubious that the version of the log4j seems to be 1.x, which support ended in 2015.
Are there any known fixes/updates?
This is not a problem.
In what way those .jar file can be exploited to trig a privilege escalation or software evasion?
The fact that Visual Studio is using old libraries doesn't shock me at all. Large companies are use to rely on third party library and then they are usually forbidden in the corner during years.
EDIT:
You question was somehow interesting and I needed to dig further.
Apparently this 0-day has been around since March, so it means 9 month ago. There is no evidence of mass exploitation but that doesn't mean that it hasn't been used in the past months.
In order to use it:
[...] an attacker only needs to get the system to log a strategically
crafted string of code. From there they can load arbitrary code on the
targeted server and install malware or launch other attacks. Notably,
hackers can introduce the snippet in seemingly benign ways, like by
sending the string in an email or setting it as an account username.
This means that hypothetically you can exploit the vulnerability through SSIS in this scenario:
Create an SSIS package that ask for an input to the client user
The package must use log4j for logging
The user enter the malicious crafted string of code
...then yes in this case an SSIS package could be exploited.
I will try it out in my spare time and I will let you know.
EDIT 2:
After extensive research I can confirm you that this is not a problem because only version Log4j 2.X are impacted:
Mitigation
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques
below.
Use log4j-finder developed by FOX IT to enumerate vulnerable log4j files on your machines.
Microsoft have now removed the dependency
There is a new version (3.16) of the SSIS tools for VS2019 which removes the dependency for log4j.
Here's the download link:
https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
Version 3.16 Upgrade Notes

Do I need MySQL commercial License for my mobile App selled to users?

I am creating a multi platform application and want to use MySQL as the database behind. I read about GPL License. The license wants me to publish my source code, if I use the free version of MySQL. I dont want to publish my source code.
So is it allowed to use MySQL as the database and build for example an mobile App with Android, that uses the data from there, without publishing my Android source code?
Thank you
You don't need to bundle MySQL with your Android; You probably host your MySQL along with your web server, isn't it?
So, the answer is No, you don't need commercial license for your App.
At first please have a look at the MySQL licensing page what model really applies to your software.
I think as long as you only want to connect to a MySQL database you somehow can do what you want (but don't bundle the client libraries). The rule of thumb is don't include/bundle anything from Oracle/MySQL and you are on the good side.
It is ok if the user downloads and installs the MySQL-package, but it is not you who delivers it with your software (which would be bundling again).
I think it is also ok to write a script which automatically downloads and installs it from the Oracle pages (note - there are better ways: e.g. dpkg), but I'm not a licensing expert.
The GPL FAQ might help you to get a sense for using and publishing GPLed software.
An overview/comparison of free and open-source software licenses can be found at Wikipedia.
Hope that helped a bit.
*Jost

Is there an API or tool that can automate software updating?

Is there any API or tool that can automate software updating? It should take care of checking for updates from a URL for a provided list of files and downloading and replacing the ones that need updating. It would also be nice if it contained an authentication module so that only authorized parties could access the updates. It should be language-agnostic - takes a list of files without extra knowledge except their versions and replaces them with newly downloaded copies if on the site there are newer versions.
I'm specifically interested in something for the Windows platform, that would run on Win Xp to Win 7.
This makes me think about apt-get ...
take a look here, as well: Is there an auto-update framework for C++/Win32/MFC (like Sparkle)?
I did see some articles a while back about embedding subversion into your application to manage version control.
Edit:
http://svnbook.red-bean.com/en/1.5/svn.developer.html
Subversion has a modular design: it's implemented as a collection of libraries written in C. Each library has a well-defined purpose and application programming interface (API), and that interface is available not only for Subversion itself to use, but for any software that wishes to embed or otherwise programmatically control Subversion. Additionally, Subversion's API is available not only to other C programs, but also to programs written in higher-level languages such as Python, Perl, Java, and Ruby."
Just saw UpdateNode launching a pretty cool update and messaging system. It seems to be cross platform and free for Open Source.
UPDATE, did some further analysis on that, posted at: https://stackoverflow.com/a/22528011/3257300
For windows, I'd use Google Update, also known as omaha.
Since you didn't tag this question as windows, I'd also mention a UpdateEngine for Mac.
And (best of all) apt, which is available for free on all Debian-based Linux and BSD distributions, like Ubuntu
There is open source project WIPT inspired by APT of Debian Linux.
Head over to Launchpad and use a PPA: it is a Debian/Ubuntu repository management platform. Of course this is not really platform independent but it is language wise :-)
You should take a look at ClickThrough, I don't know much about it but it sounds similar to what you're looking for. As for authorization, I would imagine this to be handled by your webserver based on the URL.
InstallShield has an offering. Never used it but researched it a few years back but we decided on a roll your own solution.
InstallShield Update Manager
InstallShield Update Service
You didn't state what platform you needed this for. The easiest way I can think of doing this is with subversion using rsync.
The concept is to write a post-commit hook for subversion. This script would update a "working folder" on the repository machine and then use rsync to update the differences to another machine.
Data protection and authentication would be set up using rsync over ssh.
If this is for windows, you could try doing the same with cygwin installs on the two machines.
Good luck.
If you use .NET, I'm a happy customer of AppLife Update
CRONw is a scheduled execution service for Windows. (Sorry, I can't link it, I'm apparently limited to 1 as a new user. It's hosted on Sourceforge.)
Powershell is a Windows scripting language (Microsoft-official) that allows you to do most system administration operations you could conceivably want to do. It is very easy to pick up even if you haven't worked with it before.
I would say your best bet is to write a simple update script in Powershell and, optionally, set it up as a crontask so you don't have to manually execute it.
IIRC, Powershell is an optional install on XP, and CRONw requires you be running a 32-bit system. You didn't say, so I'd guess you're doing 32-bit, but the alternative bears mentioning.
And in all this, I'm assuming that the URLs you're describing are designed for this purpose - if they're not and you don't own them, it will rapidly become more suffering than you're willing to bear. (Making a computer navigate a human-readable website usually does.)

Defining a runtime environment

I need to define a runtime environment for my development. The first idea is of course not to reinvent the wheel. I downloaded macports, used easy_install, tried fink. I always had problems. Right now, for example, I am not able to compile scipy because the MacPorts installer wants to download and install gcc43, but this does not compile on Snow Leopard. A bug is open for this issue, but I am basically tied to them for my runtime to be usable.
A technique I learned some time ago, was to write a makefile to download and build the runtime/libs with clearly specified versions of libraries and utilities. This predates the MacPorts/fink/apt approach, but you have much more control on it, although you have to do everything by hand. Of course, this can become a nightmare on its own if the runtime grows, but if you find a problem, you can use patch and fix the issue on the downloaded package, then build it.
I have multiple questions:
What is your technique to prepare a well-defined runtime/library collection for your development?
Does MacPorts/fink/whatever allows me the same flexibility of rehacking if something goes wrong ?
Considering my makefile solution, when my software is finally out for download, what are your suggestions about solving the potential troubles between my development environment and the actual platform on my user's machines ?
Edit: What I don't understand in particular is that other projects don't give me hints. For example, I just downloaded scipy, a complex library with lots of dependencies. Developers must have all the deps setup before working on it. Despite this, there's nothing in the svn that creates this environment.
Edit: Added a bounty to the question. I think this is an important issue and it deserves to get more answers. I will consider best those answers with real world examples with particular attention towards any arisen issues and their solution.
Additional questions to inspire for the Bounty:
Do you perform testing on your environment (to check proper installation, e.g. on an integration machine) ?
How do you include your environment at shipping time ? If it's C, do you statically link it, or ship the dynamic library, tinkering the LD_LIBRARY_PATH before running the executable? What about the same issue for python, perl, and other ?
Do you stick to the runtime, or update it as time passes? Do you download "trunk" packages of your dependency libraries or a fixed version?
How do you deal with situations like: library foo needs python 2.5, but you need to develop in python 2.4 because library bar does not work with python 2.5 ?
We use a CMake script that generates Makefiles that download (mainly through SVN)/configure/build all our dependencies. Why CMake? Multiplatform. This works quite well, and we support invocation of scons/autopain/cmake. As we build on several platforms (Windows, MacOSX, a bunch of Linux variants) we also support different compile flags etc based on the operating system. Typically a library has a default configuration, and if we encounter a system that needs special configuration the configuration is replaced with a specialized configuration. This works quite well. We did not really find any ready solution that would fit our purpose.
That being said, it is a PITA to get it up and running - there's a lot of knobs to turn when you need to support several operating systems. I don't think it will become a maintainance-nightmare as the dependencies are quite fixed (libraries are upgraded regularly, but we rarely introduce new one).
virtualenv is good, but it can't do magic - e.g. if you want use a library that just MUST have Python 2.4 and another one that absolutely NEEDS 2.5 instead, you're out of luck. Nor can virtualenv (or any other tool) help when there's a brand new release of an OS and half the tools &c just don't support it yet, as you mentioned for Snow Leopard: some problems are just impossible to solve (two libraries with absolutely conflicting needs within the same build), others just require patience (until all tools you need are ported to the new OS's release, you just need to stick with the previous OS release).

How to preserve build environment during product lifecycle

What are best practices in recording build/test machine(s) setup during the life time of a project? If you need to provide a patch for previous version of your product, you likely need to reload the same compiler and support tools to re-issue the patched release. What and how do you record? The obvious things are:the OS version and patch level, compiler/IDE version and patch level 3rd party tools/libraries.
My first thought is to keep a log file of all the requirements. This log file would go into your VCS.
VMWare Virtualization(or other similar products) are ideal for this type of thing. Build an entire development/build/ or test environment, and leave it setup just for that purpose. You can take the image off-line, back it up to a DVD and simply turn it back on when you need it.
I'm using maven for java with the enforcerer plugin so all of these things are stored in my project object model, even the version of maven itself which is required. As long as I manage to get the proper version from version control I'm home free.
3rd party tools and libraries go in version control along with everything else; we have a libs tree that goes under our VCS trunk right next to our app tree, so it gets included with any branches or tags that we create. The one wrinkle I haven't yet solved is Windows tools and libraries that require their own installers instead of running out of whatever directory VCS gives them.
For OS and compiler, I'd recommend creating a VM for each release if you can't install multiple compiler versions in parallel. Then your project wiki can document which VM and which compiler version to use for a given build. This isn't automatic like your log file would be, but it provides a ready-to-go environment (instead of potentially having to reinstall a machine to match your log file). Some projects check their entire compiler into version control, but this seems overkill to me (and doesn't play well with IDEs and compilers that need their own installers).
We don't track patch levels for the OS and compiler. I realize that it's possible that a patch would break or change something, but the chance seems so low that the cost-benefit ratio just isn't there.