[Pharo-users] Insecure issue tracker registration

Marcus Denker marcus.denker at inria.fr
Fri Jun 15 09:00:44 EDT 2018


Hi,

I have found a simple workaround (not yet the final solution):

Please check:

	https://tracker.pharo.org/issues-register-service

> On 15 Jun 2018, at 13:56, Tim Mackinnon <tim at testit.works> wrote:
> 
> I think Let’s Encrypt can be your friend (that seems to be the instructions all of the providers give - e.g. https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04 <https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04>).
> 
> Alternatively - and this applies more to Pharo.org <http://pharo.org/> - why not stick it on Netlify (https://www.netlify.com/docs/welcome/ <https://www.netlify.com/docs/welcome/>) which does https for you. I was amazed how much it does by checking your site off git and even offers some dynamic hooks too.
> 
> I am still sizing up porting my metalsmith generated site to something pillar based - but the concept is the same and depending on how you do things, it might be quite trivial.
> 
> Tim
> 
>> On 15 Jun 2018, at 10:15, Marcus Denker <marcus.denker at inria.fr <mailto:marcus.denker at inria.fr>> wrote:
>> 
>> Hello,
>> 
>> yes, we really need to setup SSL for that server. I will have a look next week.
>> 
>>> On 13 Jun 2018, at 10:25, Manuel Leuenberger <leuenberger at inf.unibe.ch <mailto:leuenberger at inf.unibe.ch>> wrote:
>>> 
>>> Hi,
>>> 
>>> I announced my concerns on Discord already, but got no reaction, so I post it here as well to have it properly archived.
>>> 
>>> "A colleague just noticed that the registration for the issue tracker is HTTP-only. This is not an appropriate choice for sensitive data like a password. Any possibilities to make this HTTPS-only?
>>> Link: http://tracker.pharo.org/issues-register-service <http://tracker.pharo.org/issues-register-service>, setting https:// manually does not work"
>>> 
>>> From my perspective this is a serious problem that should be quickly addressed, it's not just a nice to have feature. Not treating sensitive data with proper care leaves an image of not caring about user security and looks unprofessional. I don't think that is what Pharo needs.
>>> 
>>> Cheers,
>>> Manuel
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20180615/659c796a/attachment-0001.html>


More information about the Pharo-users mailing list