Set up Pretty Good Privacy (PGP) Key in Ubuntu



Pretty Good Privacy (PGP) is a data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. [1]


In our case we would use GNU OpenPGP implementation which is Gnu pg or gpg. GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. [2]

Generate PGP keys


# Command to create gpg key

gpg  –gen-key


Before you hit this command, you may need to install rng-tools. During the key generation operation, your system tells you that no more random bytes are available and that it needs to collect more entropy, and you are stuck. rng-tools helps in this regards. First we need to install rng-tools and need to updated /etc/default/rng-tools file  to add the line HRNGDEVICE=/dev/urandom. Follow [3] for details.


sudo apt-get install rng-tools

#start the service

sudo /etc/init.d/rng-tools start



Now, gpg  –gen-key would possibly work successfully.


Screenshot 2016-03-28 22.20.55.png

Generating pgp key



Publish PGP key:



To publish GPG keys in ubuntu server, run following commands

gpg --keyserver --send-keys 47BBA6FC
Your public key (fingerprint) would look something like following

Screenshot 2016-03-28 22.29.30.png

Listing pgp fingerprint


Finally, you can make sure your public key exists on the ubuntu server by
searching it with your email address.



Screenshot 2016-03-28 22.31.26.png

Searching gpg key by email address


Now hopefully, you can find your pgp keys on the server. So, finally, you
a public key of your own published.


Export and Import Public and Private keys:

#export public key

gpg –export -a “name of key holder” > public.key

#import private key

gpg –export-secret-key -a”name of key holder” > private.key








Categories: Uncategorized, Unix

Mutability vs Immutability in java

Whole post is a copy from [1]

Well, there are a couple aspects to this. Number one, mutable objects without reference-identity can cause bugs at odd times. For example, consider a Person bean with an value-based equals method:


Map<Person, String> map = ...
Person p = new Person();
map.put(p, "Hey, there!");

map.get(p);       // => null

The Person instance gets “lost” in the map when used as a key because it’s hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. Theorists like to harp on this point, but in practice I haven’t found it to be too much of an issue.


Another aspect is the logical “reasonability” of your code. This is a hard term to define, encompassing everything from readability to flow. Generically, you should be able to look at a piece of code and easily understand what it does. But more important than that, you should be able to convince yourself that it does what it does correctly. When objects can change independently across different code “domains”, it sometimes becomes difficult to keep track of what is where and why (“spooky action at a distance”). This is a more difficult concept to exemplify, but it’s something that is often faced in larger, more complex architectures.


Finally, mutable objects are killer in concurrent situations. Whenever you access a mutable object from separate threads, you have to deal with locking. This reduces throughput and makes your code dramatically more difficult to maintain. A sufficiently complicated system blows this problem so far out of proportion that it becomes nearly impossible to maintain (even for concurrency experts).


Immutable objects (and more particularly, immutable collections) avoid all of these problems. Once you get your mind around how they work, your code will develop into something which is easier to read, easier to maintain and less likely to fail in odd and unpredictable ways. Immutable objects are even easier to test, due not only to their easy mockability, but also the code patterns they tend to enforce. In short, they’re good practice all around!



With that said, I’m hardly a zealot in this matter. Some problems just don’t model nicely when everything is immutable. But I do think that you should try to push as much of your code in that direction as possible, assuming of course that you’re using a language which makes this a tenable opinion (C/C++ makes this very difficult, as does Java). In short: the advantages depend somewhat on your problem, but I would tend to prefer immutability.




Categories: java hacks, Uncategorized

Subtleties of the OOP Principles

This is some of the definition of basic OOP principles I came across the Internet.


“One point of confusion regarding abstraction is its use as both process and an entity. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. Abstraction, as an entity, denotes a model, a view, or some other focused representation for an actual item.”

Information Hiding:

“Its interface or definition was chosen to reveal as little as possible about its inner workings.” — [Parnas, 1972b]

“Abstraction can be […] used as a technique for identifying which information should be hidden.”

“Confusion can occur when people fail to distinguish between the hiding of information, and a technique (e.g., abstraction) that is used to help identify which information is to be hidden.”


“It […] refers to building a capsule, in the case a conceptual barrier, around some collection of things.” — [Wirfs-Brock et al, 1990]

“As a process, encapsulation means the act of enclosing one or more items within a […] container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items.”

“If encapsulation was ‘the same thing as information hiding,’ then one might make the argument that ‘everything that was encapsulated was also hidden.’ This is not obviously not true.”


In comparison: “Abstraction, information hiding, and encapsulation are very different, but highly-related, concepts. One could argue that abstraction is a technique that help us identify which specific information should be visible, and which information should be hidden. Encapsulation is then the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible.”

Polymorphism [1]:

Polymorphism is a long word for a very simple concept.

Polymorphism describes a pattern in object oriented programming in which classes have different functionality while sharing a common interface.

The beauty of polymorphism is that the code working with the different classes does not need to know which class it is using since they’re all used the same way. A real world analogy for polymorphism is a button. Everyone knows how to use a button: you simply apply pressure to it. What a button “does,” however, depends on what it is connected to and the context in which it is used — but the result does not affect how it is used. If your boss tells you to press a button, you already have all the information needed to perform the task.

In the programming world, polymorphism is used to make applications more modular and extensible. Instead of messy conditional statements describing different courses of action, you create interchangeable objects that you select based on your needs. That is the basic goal of polymorphism.







Categories: java hacks, Uncategorized

Java Collection, List, Set

In Java List, Set or Collection all mean collection of items. But there are some subtle difference in them when you put your feet in Java world.


In fact, List and Set are special type of Collection in Java. Collection are just group of items where you can add or remove items, search for items and so on.


On the other hand, List is a sequential collection of items. For example, you may want to find 5th element from a List which does not carry enough semantics in Collection.


On another side, Set is yet another special type of collection where there cannot be any member duplicated. Java Util Set basically give an abstract of mathematical set.


Following figure from [1] explains the relation between Collection, Set and List (and others) in term of Java Interface hierarchy.









Categories: java hacks, Uncategorized

Deep copy, shallow copy analogy from security perspective

Copy Constructor is about deep copying of java objects. Deep copy of objects are important for security and maintainability of java codes. I will not explain copy constructor or deep copying and shallow copying, Instread, I will try to give some analogy of deep or shallow copying.


  1. Suppose, we have a photograph of somebody (some kind of copying). Now, how terrible it will be if by hurting the photograph,  someone can hurt the person in the photograph ? Deep copying from the sense of security is  having a photograph (or shadow) by hurting it, you cannot hurt the person.
  2. On the other hand, shallow copying is analogous of having the twin of the victim where there is some string attached.



Categories: Uncategorized

Copy Constructors in Java

11th Hour

Hi all,

We have a new topic over here to learn – The Copy Constructors.


A copy constructor is a constructor that takes only one argument which is of the type as the class in which the copy constructor is implemented. For example, let us assume a class namely Car and it has a constructor called copy constructor which expects only one argument of type Car.


Copy constructors are widely used for creating a duplicates of objects known as cloned objects. Duplicate object in the sense the object will have the same characteristics of the original object from which duplicate object is created. But we have to ensure that both original and duplicate objects refer to different memory locations.


It’s our responsibility to implement a copy constructor in our class in the right way. As mentioned above, it’s used to duplicate objects. So we…

View original post 428 more words

Categories: Uncategorized

DevStack Configuration Files

Here are some configuration files for devstack settings [1].



localrc is the old file used to configure DevStack. It is deprecated and has been replaced by local.conf. DevStack will continue to use localrc if it is present and ignore the localrc section in local.conf.. Remove localrc to switch to using the new file. [2]

This file contains  default passwords (for admin, database, rabitmq, etc), IP address settings and setting for services to be installed.



stackrc is the primary configuration file for DevStack. It contains all of the settings that control the services started and the repositories used to download the source for those services. stackrcsources the localrc section of local.conf to perform the default overrides. [3]

This file contain git location for the repositories to download devstack codes from.



openrc configures login credentials suitable for use with the OpenStack command-line tools. openrc sources stackrc at the beginning (which in turn sources the localrc section of local.conf) in order to pick up HOST_IP and/or SERVICE_HOST to use in the endpoints.  [4]







Categories: openstack, Uncategorized