I've updated the Docker image for
built on Alpine Linux.
This version is built on Alpine Linux 3.12.
This version removes the following plugins. I'm still thinking about some of the others, especially the GUI-related ones. The idea is of course to have the smallest possible set of plugins. Comments welcome.
The output Docker image contains the Pharo VM only and is not runnable by itself. It is intended to be used as a base to build your own Docker image containing your application-specific Pharo image.
I'll be building a similar Docker image for Pharo's fork of the VM.
I've been using web browser cookie-based login for Discord. Recently my main laptop crashed. Now using an old standby laptop, I visit Discord and am prompted for password. No problem, I have it in my password safe that is backed up regularly. Password ok, now prompted for 2FA. Hmmm, 2FA fails...
Right, seems I have been using cookie-based login for so long that, during that time, I bought a new phone and sold the old phone. For 2FA, I use Duo Mobile, and it is phone-specific:
Since Duo Mobile is tied to a specific device's hardware security module (HSM), you will need to reinstall and reactivate Duo Mobile on a new phone.
No biggie, this is only Discord. I'll make a new account. Ok done. Login again. Discord repeatedly says, for my new account, "We've detected something out of the ordinary going on. To continue using Discord, we will need you to verify your account." And the single option presented is to verify by phone. That's an easy decision: No Discord, you are not getting my mobile phone number.
A few things to think about, in no particular order, from both user and system engineering perspectives:
I am willing to use cookie-based login for Discord. Probably need not have enabled 2FA. If a user enables cookie login, perhaps prompt to turn off 2FA, or do it automatically?
With a password safe, my Discord password is randomly generated gibberish. Is that, combined with good integration of safe and browser, better than using cookie-based login? Am I applying resume-padding thinking here?
As a user, RTF2FAM. As a system engineer, expect no user to.
The corporate IT world practises periodic security credentials review. Overkill for an individual to do it like they do, but this situation has motivated me to relook at my password safe, Duo Mobile accounts and a few other things.
Think hard about asking for people's mobile phone numbers. If you do it, don't 'explain' it with weasel words like Discord has done. Yeah yeah, I'm not paying $$ to use Discord, therefore they want me to pay with my personal data. I get that. I say no.
Pharo is transitioning from OpenSSL 1.0.x to OpenSSL 1.1.1. There are C API
changes between the two OpenSSL versions that break many tests, basic things
XXX_reset() etc. As such, I've created the branches
openssl_1_1 to match the versions used by Pharo.
To load, for OpenSSL 1.0.x:
Metacello new baseline: 'OpenSSL'; repository: 'github://PierceNg/OpenSSL-Pharo:openssl_1_0/src-st'; load.
To load, for OpenSSL 1.1.x:
Metacello new baseline: 'OpenSSL'; repository: 'github://PierceNg/OpenSSL-Pharo:openssl_1_1/src-st'; load.
I've started to update Glorp and GlorpSQLite for Pharo 8. This post lists the stuff to be handled.
First, changes in Pharo from version to version. Glorp's
TimedProxyReaper uses a
weak-valued dictionary to hold
TimedProxy instances. In Pharo 6,
WeakValueDictionary>>at:put: essentially does the following:
WeakValueAssociation key: key value: anObject
In Pharo 7, that became:
WeakValueAssociation key: key value: anObject asSetElement
TimedProxy to implement
In Pharo 8,
#asSetElement is deprecated in favour of
WeakValueAssociation key: key value: anObject asCollectionElement
TimedProxy now also needs
The Pharo community has consolidated around Pharo-SQLite3 as the definitive SQLite binding going forward. GlorpSQLite uses the now-legacy UDBC-SQLite binding currently. This change should be straightforward.
Todd Blanchard has been working on Ruby on Rails-style ActiveRecord for Glorp, and testing the changes with PostgreSQL.
With independently evolving drivers for SQLite, PostgreSQL and MySQL, and the ActiveRecord work changing Glorp itself, the time has come to set up CI for Glorp.