Marco

Dependency Inversion Principle states that:

  • High level modules should not depend upon low level modules. Both should depend upon abstractions.
  • Abstractions should not depend upon details. Details should depend upon abstractions.

Achieving this will increase the reusability of the system modules by applying loose coupling to any dependencies among them. This will also make the system flexible enough to welcome and accept changes without harmful redesigning or restructuring efforts.

Note: high level modules are the ones that contain the system complex business logic and flows, and the low level modules are the ones that contain the system low level and basic operations like hardware access, network protocols...etc.

Let's consider the following class diagram that violates the Dependency Inversion Principle:

 

From the first look, we can notice that this system only reads characters from the keyboard and writes them to the printer, and nothing more. We also notice that the CopyManager (high level class) is so tightly coupled with the KeyboardReader and PrinterWriter (low level classes). Now let's consider we want to direct the output to a file or to the screen, or support to read the input characters from the screen or from a file; definitely the CopyManager will change to support these updates, and imagine that the CopyManager class contains complex business logic and flows and is hard to be tested. For sure it won't be a good practice to modify a core class like that with every single update or new added system feature.

Applying the Dependency Inversion Principle will resolve that matter, and will make the system more flexible, extendable, modifiable and testable.

A good practice to apply the Dependency Inversion Principle correctly is to revert the modules dependency while we think and design. That can be done by first defining the high level modules that contain the complex business logic that we wouldn't want to change, and then define an abstraction layer based on the high level modules needs, and make the high level modules depend on that abstraction layer. Also, to make sure we are applying the Dependency Inversion Principle right; we should seal off both the high level modules and their abstraction layer together in the same package (library), and the low level module in different package(s) (libraries); and that to guarantee total dependency isolation between the high level modules and the low level modules. Now we will not worry about the actual input sources from which we read the characters or the actual output sources to which we write them. See the diagram below that fulfills the Dependency Inversion Principle:

Monier Shokry

Introduction:

Heartbleed is not problem with SSL/TLS protocol, it’s a security bug in the open-source library openSSL library Which is wildly used to implement the internet transportation layer security (TLS) protocol. This bug is considered as Buffer-over-read where software allows more data to be read than allowed  which means it allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet .

  • Why it’s serious?
  • How to detect if you are affected ?
  • How common are the vulnerable OpenSSL versions?
  • How about operating systems?
  • How to fix it?
  • References.

Why it’s serious?

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

How common are the vulnerable OpenSSL versions?

The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating systems. A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS.

How about operating systems?

Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:

  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)

Operating system distribution with versions that are not vulnerable:

  • Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
  • SUSE Linux Enterprise Server
  • FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013
  • FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013
  • FreeBSD 10.0p1 - OpenSSL 1.0.1g (At 8 Apr 18:27:46 2014 UTC)
  • FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)

How to detect if you are affected?

 You can test if you are vulnerable by requesting a heartbeat response with a large response. If the server replies your SSL service is probably vulnerable. You can use any of the tests below:

How to fix it?

  • Upgrade the OpenSSL version to 1.0.1g

     

  • Request revocation of the current SSL certificate
  • Regenerate your private key
  • Request and replace the SSL certificate

References.

 

 

1- ReportSync:

If you have a lot of reports to synchronize between servers, download ‘Reportsync’ from the Google code project: http://code.google.com/p/reportsync/.  This tool makes it easy to synchronize a lot of content quickly across multiple servers.

2- Reporting Services Scripter:
It allows you to write scripts to move reports, data sources and all other reporting items.  The handy thing about this tool is that you can download your content to a local folder, edit the script and then use the scripts to push the content out to as many servers as you need to at the same time.
Get it here: Reporting Services Scripter
 

 

3- Reporting Services Migration Tool:

It is a Microsoft tool that can be used for migrating reports and other artifacts from SQL Server 2008 R2 and later versions report servers to the new SQL Server 2012 Report Server. This tool uses PowerShell for migration scripts. Here is the link to download the SQL Server Reporting Migration Tool