SweetAda 0.1g released

SweetAda 0.1g released

[Gabriele Galeotti]

Hi all.

I've just released SweetAda 0.1g.

This is a maintenance release, and introduces new toolchains based on Binutils 2.35, GCC 10.2.0 and GDB 10.1.

Along with new tools, the basic support libraries, e.g., GMP, MPFR, MPC, and all auxiliary
libraries were used at the highest stable version during the builds.

Sorry for a significant delay in releasing, but it is very time-consuming to keep everything in-sync, especially
when toolchains change. Neither I had the time to complete the manaul, I'll try to do that in the near future.

SweetAda itself gets few changes:
- due to a deeper Ada code analysis, the new compiler front-end showed possible superfluous aspects; they are
removed and warnings made silent
- slightly better menu scripts
- echo_log() and echo_log_error() functions in Bash scripts are now renamed as log_print() and log_print_error()
- minor changes and typos here and there

Of course, LibGCC and RTS packages are synchronized with new toolchains, so download them as well.

I am working on Insight too, hopefully packages will be available ASAP, but it is still at 20200417 timestamp. Please note that if you install Insight,
it will overwrite the standard GDB executable, and you're stuck at 9.1. GPRbuild remains at 20200417 timestamp as well.

I discovered a mismatch in QEMU for Linux 20200817 targeted for ARM, AVR, AArch64, x86 and M68k CPUs, where
executables end up being objects for an OS X platform, because of bad naming. This is now corrected.
Sorry for that, please re-download the following packages:
qemu-aarch64-20200817L.tar.xz
qemu-arm-20200817L.tar.xz
qemu-avr-20200817L.tar.xz
qemu-i386-20200817L.tar.xz
qemu-m68k-20200817L.tar.xz

Furthermore, QEMU for Windows packages lack libffi-6.dll. This is now corrected. Please re-download
qemu-<every_cpu>-20200817W.zip (or place a libffi-6.dll library taken from a random MinGW64 package, along the QEMU executable).

Find everything at https://www.sweetada.org.

By the way, the connection to SweetAda website is now completely secure. Many thanks to Certbot team.

Best regards.

Re: SweetAda 0.1g released

[Stéphane Rivière]

> Find everything at https://www.sweetada.org.

Thanks Gabriele, I will test again :)

-- 
Be Seeing You
Number Six

Re: SweetAda 0.1g released

[Gabriele Galeotti]

On Monday, November 16, 2020 at 12:52:31 PM UTC+1, Stéphane Rivière wrote:
> > Find everything at https://www.sweetada.org.
> Thanks Gabriele, I will test again :) 
> 
> -- 
> Be Seeing You 
> Number Six

You're welcome.

Re: SweetAda 0.1g released

[Keith Thompson]

Gabriele Galeotti <gabriele.galeotti.xyz@gmail.com> writes:
> Hi all.
>
> I've just released SweetAda 0.1g.
>
> This is a maintenance release, and introduces new toolchains based on
> Binutils 2.35, GCC 10.2.0 and GDB 10.1.
>
> Along with new tools, the basic support libraries, e.g., GMP, MPFR,
> MPC, and all auxiliary libraries were used at the highest stable
> version during the builds.
>
> Sorry for a significant delay in releasing, but it is very
> time-consuming to keep everything in-sync, especially when toolchains
> change. Neither I had the time to complete the manaul, I'll try to do
> that in the near future.

I suggest that an announcement like this should include, at or near the
top of the article, a brief description of what SweetAda is.

From the web site:

    SweetAda is a lightweight development framework whose purpose is the
    implementation of Ada-based software systems.

[...]

> Find everything at https://www.sweetada.org.
>
> By the way, the connection to SweetAda website is now completely
> secure. Many thanks to Certbot team.

If I visit https://www.sweetada.org it looks OK.  If I drop the "www." I
get a "Not secure" warning from my browswer (Chrome on Windows).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Re: SweetAda 0.1g released

[Gabriele Galeotti]

> If I visit https://www.sweetada.org it looks OK. If I drop the "www." I 
> get a "Not secure" warning from my browswer (Chrome on Windows). 

Thanks Keith.

I don't know exactly why, unfortunately I am not a very skilled person in website administration.

Maybe my server is responding also on a generic domain request, but it is missing the certificate,
which I registered with the exact name "www.sweetada.org".

I find configuring Apache httpd always a nightmare, when I will have some spare time, I'll try to investigate better.

Best regards, G

Re: SweetAda 0.1g released

[Mart van de Wege]

Gabriele Galeotti <gabriele.galeotti.xyz@gmail.com> writes:

>> If I visit https://www.sweetada.org it looks OK. If I drop the "www." I 
>> get a "Not secure" warning from my browswer (Chrome on Windows). 
>
> Thanks Keith.
>
> I don't know exactly why, unfortunately I am not a very skilled person
> in website administration.

That's because Let's Encrypt issued you a certificate for
www.sweetada.org, with www.sweetada.org as a Subject Alternative Name.

Subject: CN = www.sweetada.org

X509v3 Subject Alternative Name: 
   DNS:www.sweetada.org

I'd say that's a broken certificate. I have no clue why they would issue
it that way, unless you made a mistake in your Certificate Signing
Request. Unfortunately, I do not use Letsencrypt, so no clue where it
went wrong. The norm is to have a cert with Subject (in this case)
sweetada.org with www.sweetada.org as the SAN.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: SweetAda 0.1g released

[Gabriele Galeotti]

On Tuesday, November 17, 2020 at 9:30:05 AM UTC+1, Mart van de Wege wrote:

> That's because Let's Encrypt issued you a certificate for 
> www.sweetada.org, with www.sweetada.org as a Subject Alternative Name. 
> 
> Subject: CN = www.sweetada.org 
> 
> X509v3 Subject Alternative Name: 
> DNS:www.sweetada.org 
> 
> I'd say that's a broken certificate. I have no clue why they would issue 
> it that way, unless you made a mistake in your Certificate Signing 
> Request. Unfortunately, I do not use Letsencrypt, so no clue where it 
> went wrong. The norm is to have a cert with Subject (in this case) 
> sweetada.org with www.sweetada.org as the SAN. 
> 
> Mart 
> 
> -- 
> "We will need a longer wall when the revolution comes." 
> --- AJS, quoting an uncertain source.

Many thanks for your hints.
If an error exists, it's obviously mine.
I'll take into account what you say e maybe one of next weekends I'll try to correct everything.
In the meantime, use only the (apparent) secure https://www.sweetada.org connection.
Best regards
G

Re: SweetAda 0.1g released

[Mart van de Wege]

Gabriele Galeotti <gabriele.galeotti.xyz@gmail.com> writes:

> On Tuesday, November 17, 2020 at 9:30:05 AM UTC+1, Mart van de Wege wrote:
>
>> That's because Let's Encrypt issued you a certificate for 
>> www.sweetada.org, with www.sweetada.org as a Subject Alternative Name. 
>> 
>> Subject: CN = www.sweetada.org 
>> 
>> X509v3 Subject Alternative Name: 
>> DNS:www.sweetada.org 
>> 
>> I'd say that's a broken certificate. I have no clue why they would issue 
>> it that way, unless you made a mistake in your Certificate Signing 
>> Request. Unfortunately, I do not use Letsencrypt, so no clue where it 
>> went wrong. The norm is to have a cert with Subject (in this case) 
>> sweetada.org with www.sweetada.org as the SAN. 
>> 
>> Mart 
>> 
>> -- 
>> "We will need a longer wall when the revolution comes." 
>> --- AJS, quoting an uncertain source.
>
> Many thanks for your hints.
> If an error exists, it's obviously mine.
> I'll take into account what you say e maybe one of next weekends I'll try to correct everything.
> In the meantime, use only the (apparent) secure https://www.sweetada.org connection.
> Best regards
> G

Since we have the key fingerprints, and the certificate is the same,
both connection are equally secure.

Don't let yourself be frightened by the security theatre around
certificates. The *only* thing they prove is that a private key that
belongs to the name in the public key that was certified by a CA
(Letsencrypt in this case) is on the server you're connecting to. That's
all. There is nothing more the SSL/TLS protocols can prove.

So the server answering to sweetada.org has access to the same key as
the server answering to www.sweetada.org. And we know it's the same
server. Since Letsencrypt certified that the key belonging to the
www.sweetada.org certificate should be the one presented, and it is,
that means both servers are equally 'secure'.

Note that I said nothing about whether or not it is a malicious server
or not; that's not something SSL/TLS can answer.

So don't worry. We know about it, and letsencrypt should normally let
you fix this easily.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: SweetAda 0.1g released

[DrPi]

Le 16/11/2020 à 22:37, Gabriele Galeotti a écrit :
> 
>> If I visit https://www.sweetada.org it looks OK. If I drop the "www." I
>> get a "Not secure" warning from my browswer (Chrome on Windows).
> 
> Thanks Keith.
> 
> I don't know exactly why, unfortunately I am not a very skilled person in website administration.
> 
I don't have any web administration skill either.
For letsencrypt certificate management, I use cerbot (with nginx) : 
https://certbot.eff.org/

It's very easy to use.

regards,
Nicolas


> Maybe my server is responding also on a generic domain request, but it is missing the certificate,
> which I registered with the exact name "www.sweetada.org".
> 
> I find configuring Apache httpd always a nightmare, when I will have some spare time, I'll try to investigate better.
> 
> Best regards, G
> 

Re: SweetAda 0.1g released

[Gabriele Galeotti]

On Tuesday, November 17, 2020 at 2:50:05 PM UTC+1, Mart van de Wege wrote:
> Since we have the key fingerprints, and the certificate is the same, 
> both connection are equally secure. 
> 
> Don't let yourself be frightened by the security theatre around 
> certificates. The *only* thing they prove is that a private key that 
> belongs to the name in the public key that was certified by a CA 
> (Letsencrypt in this case) is on the server you're connecting to. That's 
> all. There is nothing more the SSL/TLS protocols can prove. 
> 
> So the server answering to sweetada.org has access to the same key as 
> the server answering to www.sweetada.org. And we know it's the same 
> server. Since Letsencrypt certified that the key belonging to the 
> www.sweetada.org certificate should be the one presented, and it is, 
> that means both servers are equally 'secure'. 
> 
> Note that I said nothing about whether or not it is a malicious server 
> or not; that's not something SSL/TLS can answer. 
> 
> So don't worry. We know about it, and letsencrypt should normally let 
> you fix this easily.
> Mart 
> 
> -- 
> "We will need a longer wall when the revolution comes." 
> --- AJS, quoting an uncertain source.

Thanks a lot Mart.
Anyway,  to have a flag of a site not secure from the browser is aesthetically unpleasant,
I'll try to slowly fix it in the future, no problem.
Best regards
G

Re: SweetAda 0.1g released

[Gabriele Galeotti]

On Tuesday, November 17, 2020 at 7:48:57 PM UTC+1, DrPi wrote:
> I don't have any web administration skill either. 
> For letsencrypt certificate management, I use cerbot (with nginx) : 
> https://certbot.eff.org/ 
> 
> It's very easy to use. 
> 
> regards, 
> Nicolas
Thanks Nicolas,
I'm actually using Certbot and letsencrypt with Apache httpd indeed.
Best regards, G

Re: SweetAda 0.1g released

[DrPi]

Le 18/11/2020 à 09:38, Gabriele Galeotti a écrit :
> On Tuesday, November 17, 2020 at 7:48:57 PM UTC+1, DrPi wrote:
>> I don't have any web administration skill either.
>> For letsencrypt certificate management, I use cerbot (with nginx) :
>> https://certbot.eff.org/
>>
>> It's very easy to use.
>>
>> regards,
>> Nicolas
> Thanks Nicolas,
> I'm actually using Certbot and letsencrypt with Apache httpd indeed.
Great !

I have setup a redirection from mydomain.myextension to 
www.mydomain.myextension in nginx configuration file.

This is easy to do (at least with nginx) and fixes the kind of problem 
you have since cerbot also manages the redirection.

Regards,
Nicolas
> Best regards, G
>