Monthly Archives: June 2017

About PBKDF2 salt

I’m playing with the PBKDF2 package of Udo:!/~UdoSchneider/PBKDF2
(thanks Udo), but I can’t find how to validate a stored hash.
Can you point me in the right direction?



Looks like you’ll have to store the salt when making the original hash of the

With that you can do

| salt originalPassword userInputPassword originalHash  newHash secretKey |
originalHash:=PBKDF2 derivedKeySHA1Password: originalPassword salt: salt.
newHash:=PBKDF2 derivedKeySHA1Password: userInputPassword salt: salt.

secretKey:= SecureRandom new nextBytes: 16.

((SHA256 new hmac key: secretKey) digestMessage: originalHash) = ((SHA256
new hmac key: secretKey) digestMessage: newHash).

We do the double SHA256 HMAC signing of the hashes because of

You can store the #secretKey and each user should get a new #salt every time
they change their password and you shouldn’t reuse the salts for other users
or password.

For PBKDF2 there is probably a max (or recommended) salt length but I don’t
know it.

I also don’t know anything about the SecureRandom class but it says it on
the tin, so maybe it is.  Maybe not though.  I don’t know how to find out.
But I don’t know that it matters in this instance as its only used for the
SHA256 HMAC internally in the comparison function.

Hope this helps.

P3 is a modern, lean and mean PostgreSQL client for Pharo

P3 is a modern, lean and mean PostgreSQL client for Pharo.

P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types.

With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal.

More info, usage examples and code at

P3 is written in pure Pharo, using a TCP network connection to PostgreSQL.

This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release.

To load: The default group loads P3Client and its basic dependencies NeoJSON and ZTimestamp

Metacello new
baseline: ‘P3’;
repository: ‘github://svenvc/P3’;

The glorp group loads P3DatabaseDriver and the whole of Glorp (warning: large download)

Metacello new
baseline: ‘P3’;
repository: ‘github://svenvc/P3’;
load: ‘glorp’.


PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban !

Pharo 7 provisional HOWTO


this mail describes how to start to send pull requests to Pharo 7 Github repository from Pharo 7.
– you need to have a Github account and set SSH keys. See
– create own pharo-project/pharo repository fork. Go to, click on “Fork” button and follow the instructions
Get Pharo 7 image
The CI jobs for the Pharo 7 defelopment are currently not fully set and we still do not publish Pharo 7 image to so you cannot get it using zero-conf scripts. But we have a provisional CI job that bootstraps the Pharo 7 image.
There download a file named like and decompress it. Unlike Pharo 6 images, the archive contains three files. Image, changes and sources. In Pharo 7 you have the sources file for every bootstrapped version. It has a commit hash in the name and it cannot be shared between different Pharo 7 imges, however it can be shared between images that were created as snapshots with the same bootstrapped image as ancestor.
Create local clone
You need a local clone of the Pharo repository. Because it contains a lot of small files, it is not a good idea to have own clone for every image. You can have only one and share them between images. But because of some current Monticello constraints you need to have the clone placed in the image directory in a folder with name ‘pharo-core’.
In this step we will clone the Pharo repository from pharo-project/pharo Github repository and add your fork as default pull target. We will update your fork repository to contain all latest commits from the Pharo repository in the branch named ‘development’. For latest stable version (Pharo 6) we use the master branch.
In the end we will checkout the repository to a particular commit from which the downloaded Pharo 7 image was bootstrapped. Imagine that you have a Pharo 7 image that is several days old and the development branch has already some commits that change code. If you would take this older image, checkout to the development branch and then do your commit, your would revert all changes done in not-loaded commits. The other option is to update your image to correspond to the repository latest commit which requires packages reloading.
If you checkout to a particular commit, you are in detached HEAD state. In this state you cannot do commits directly. You need to firstly create new a new branch which we will do anyway.
Evaluate the following code. This functionality will be later direct part of Iceberg UI. Do not forget to change the user name.
username := ‘YOUR-USER-NAME’.
repository := IceRepositoryCreator new
url: ‘’;
location: (‘pharo-core’ asFileReference ensureCreateDirectory);
repository checkoutBranch: ‘development’.
repository register.
fork := (IceRemote name: ‘myFork’ url: (‘{1}/pharo.git’ format: {username})).
repository addRemote: fork.
repository pushRemote: fork.
repository pullRemote: repository origin.
“update fork”
repository backend pullFrom: repository origin. “use this low-level form to prevent packages reloading”
repository push.
“checkout to the commit from which the image was bootstrapped”
repository checkoutBranch: (SystemVersion current commitHash).
Use already created clone
This is alternative to the previous step. Let’s suppose that you already have your local clone. You take some Pharo 7 image and you want to create commits. Then you need to create a symlink or move/copy the repository into your image directory. Remember, it must be named pharo-core (we do not use the name ‘pharo’ to avoid collision with VM executable).
In this step we will register an existing Pharo repository clone, set your fork as the push target, update your fork and then switch to the particular commit.
repository := IceRepositoryCreator new
location: (‘pharo-core’ asFileReference);
repository register.
fork := repository remotes detect: [ :remote | remote remoteName = #myFork ].
repository pushRemote: fork.
repository pullRemote: repository origin.
repository checkoutBranch: ‘development’.
repository backend pullFrom: repository origin.
repository push.
repository checkoutBranch: (SystemVersion current commitHash).
Issue processing
– create new case on FogBugz to get the issue number
– open Iceberg and from the context menu on the ‘pharo’ repository do: Pharo – Create new branch from FogBugz issue, enter the issue ID and it will fill the full branch name for you
– create your changes (you can do it before the creation of the branch too)
– commit and push your changes in Iceberg, this way you will commit your branch to your fork repository. Remember that the Iceberg commit window has two buttons, one for local commit, the second for commit with immediate push. They can be very long because they contain the full branch (issue) name
– in Iceberg in the ‘pharo’ repository context menu do: Pharo – Create pull request, fill your
– fill your Github credentials
– leave the PR title, comment is not required, check the pull request head and base. The base MUST be pharo-project/pharo development. Create the pull requests
– go to, check your pull requests and put URL of it into the issue record on FogBugz (as a comment). Resolve the issue as Fix review needed
— Pavel

Github Pharo 70 dev on the starting blocks


in fact the development of Pharo 7 has already started. But in a limited mode.
For Pharo 7 we have the #development branch on GitHub (pharo-project/pharo)
…and we are already merging pull requests.
We currently have (mostly technical) problems with the infrastructure so the monkey is not running. But we have a temporary CI jobs that can check specific pull request (that means that we bootstrap Pharo for them and run tests for all platforms).
The latest Pharo 7 image can be found here:
The image is currently not uploaded to and it is not accessible by zero-conf scripts, sorry.
If you want to try to create own pull request directly from Pharo 7, you need to do this:
– create own fork of pharo-project/pharo repository on GitHub and keep it in sync
– download Pharo 7 image
– clone pharo-project/pharo repository into the image directory, the directory with the clone MUST be named “pharo-core”
– checkout the development branch or better checkout the commit from which the Pharo 7 image was bootstrapped (SystemVersion current commitHash). Beware, in that case you will be in detached head state (you need to create own issue branch later to be able to commit something). The checkout to a particular commit cannot be done currently from Iceberg, you need to use git
– add your fork repository as a remote and mark it as default push target
– create issue on FogBugz to get issue ID
– create a branch for this issue (can be done easily from the repository context menu in Iceberg [Pharo], this option is valid only if you cloned pharo-project/pharo repository)
– commit the fix to your fork repository
– create the pull request (can be done easily from the repository context menu in Iceberg [Pharo], this option is valid only if you cloned pharo-project/pharo repository)
– add link to the pull request into the FogBugz issue entry
Pull requests can be done from Pharo 6 too. Then you do not need to have clone in “pharo-core” directory, it can be everywhere, and you mast create your branches from the master branch (and create pull requests on #development)
Because we currently have limited possibilities to check pull requests, we prefer to merge PRs needed for start of the new integration process. We really do not need to break the system in this fragile state 😉
— Pavel

Geo location data reading with Zinc: a Breeze

|client znResponse|
client := ZnClient new.
client host: ‘’.
client addPathSegment: ‘’.
client queryAt: ‘ip’ put: ‘’.
client contentReader: [ :entity | STONJSON fromString: entity contents ].
znResponse := client get; contents.

While waiting for the PullRequest menu in Pharo70


Of course we just want you to have to

  • enter a bug entry
  • and create a pullrequest using a magic button to send a fix to Pharo.

Now before getting there, here is a description of what we will use.



we still do not have official guidelines but this should help you:
1) you need own fork of pharo-project/pharo repository
2) clone pharo-project/pharo into directory named “pharo-core” in your working directory. You can do it from Iceberg (Clone repository) or by this script:
Iceberg enableMetacelloIntegration: true.
target := ‘pharo-core’ asFileReference ensureCreateDirectory.
repository := IceRepositoryCreator new
remote: (IceRemote url: ‘’);
location: target;
repository backend checkoutBranch: ‘master’.
repository addRemote: (IceRemote name: ‘myFork’ url: ‘’).
repository register.
Do not forget to change your fork URL. If you will do  it from Iceberg, you need to add remote manually.
3) set your fork remote as default push remote
4) create issue on FogBugz. You will obtain issue number e.g. 12345
5) in repository context menu in Iceberg and do Pharo-Create new branch from FogBugz issue, you will enter the issue number and the dialog wil fill the full branch name
6) do you changes and commit (and push) them to your fork repository
7) in repository context menu in Iceberg do: Pharo-Create pull request. Login, by default the title will be set to the branch name, let it be, comment is not needed. “From” will be your fork and your issue branch. “To” will be pharo-project/pharo and “development” branch
8) as soon as you create the pull request, add URL to this pull request to the FogBugz issue and mark it as resolved (fix review needed).
You need not to do it exactly this way, e.g. you can create the pull request from Github web interface, but the pull request name must contain the the issue number. And your issue must contain link to the pull request.
— Pavel

Pharo 6 snap package for Ubuntu

Hi Everyone,

I’ve updated the Pharo 6 snap package for Ubuntu.

The major advantages of using the snap package are:

– No need to install all the 32 bit dependencies on a 64 bit system,
they’re all contained and isolated within the snap package.
– Automagically distinguish between 32 bit and 64 bit images and run the
appropriate VM (as with the ZeroConf package, the 64 bit VM still
needs more testing).

To get Pharo up and running on Ubuntu 16.04 or later:

# Install Pharo
$ sudo snap install –candidate pharo –classic
# If your system isn’t configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go…
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo

If you’re on Debian or Ubuntu 14.04 you’ll need to install snapd, see

The VM is the threaded heartbeat, dated 201705310241.

The installation flags are:

–candidate – The edge and beta channels are for development versions.
It progresses to candidate and then stable.
–classic – Snap packages are normally sandboxed for security
reasons.  Since Pharo is a development environment
in which we want to be able to run any executable,
or load any library, it is installed with access to
the entire system (as the running user).

Why use snap packages?

– They include all dependencies.  In particular, for the 32 bit
versions, this means that it isn’t necessary to install all the 32 bit
architecture and associated dependencies.
– Including dependencies means that there shouldn’t be any problems with
incompatible library versions when upgrading.

Why not use snap packages?

– It’s a relatively new technology, with a number of rough edges.
– There may still be issues with its sandboxing that I haven’t
discovered yet.
– Because the package uses classic confinement, it isn’t
cross-distribution in practice (unfortunately).

Please let me know of any other advantages or disadvantages you think
should be listed here.

If you don’t trust me to configure your system correctly (which requires

– All the scripts that make up the sub-commands are visible, e.g.
pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG

The packaging code is at:


Ephemeric Cloud


I just wanted to make some clarifications on what is going on with
PharoCloud and how I see the future of the project.

PharoCloud is not closing, but just dropping VM hosting support. We will
continue to develop and maintain Ephemeric Cloud which allows you to publish
Pharo web applications online much easier than any other VM hosting can
offer. In some way PharoCloud just becomes more “cloudy” by dropping
outdated technologies off 🙂

Our plan is to make the project more community oriented. We integrated
PharoCloud with SSO and provide *FREE* access to all *Pharo
Association* members. You are welcome to log in to the cloud with your Pharo
Association account at:

We are encouraging you to migrate your applications hosted as Pharocloud VMs
to the Ephemeric Cloud. It is much more simple! We have some positive
experience already. There are some examples I moved from VM hosting to
Ephemeric Cloud:

Here you can find a quick start guide to Ephemeric cloud and some tips on
how to publish your app:

Also there is a REST API you can use to manage the cloud. And there is also
a Pharo wrapper around the REST-API:

We also have video guides:
quickstart (sorry for old UI of the manager)
curl example:

In case of any questions or issues with images, please feel free to contact

Mike Filonov