Re: [Dragora-members] Current Status

[Matias Fonzo]

El 2020-06-21 15:29, Michael Siegel escribió:
> Am 21.06.20 um 04:24 schrieb Matias Fonzo:
>
> > We met my wife and daughter waiting for our next child, little
> > brother. In May we started a construction project here at my house,
> > taking advantage of the fact that the quarantine has been released a
> > little bit here (until Jun 28) since there is no Pandemic in this
> > city, we are and I am particularly very stressed since I was behind
> > the workers and getting all the materials as possible to advance the
> > time, we believe that the baby is coming next week.  We are very
> > happy and at the same time very tired and busy so that this
> > construction can be finished, now that it can, because I think that
> > at the end of the year or next year it will be impossible to build
> > anything, due to the prices and because I also think that the
> > powerful people of the world do not want anyone to have their/a
> > house...
> >
> > I mention the construction site because it will be my new workspace
> > (there in the background, courtyard).  That's right, they sent me
> > back! :-)
> >
> > I am currently occupying a whole room for the computer and music
> > stuff, and we hope to have this space available for when the baby can
> > occupy it.
>
> Well then, best of luck with all of this to you and your family!

Thanks!

> > All along the way I've been trying to do things for Dragora, to say
> > the least, some of the relevant changes I've made and I'm working on
> > them:
> >
> > - I've been testing Qi 2.0 and I think it's ready, I'll soon send a
> > version here for comments or testing, if possible.
>
> Nice.
>
> > - The name of the architectures we provide for the packages has
> > changed, mainly:
> >
> > "x86_64" is now called "amd64". "i586" remains under the same name.
> >
> > - I have adjusted the rest of the targets (from the cross compiler)
> > for possible architectures that could be provided in the future, in
> > the case of ARM they are now distinguished: armfp, armhf, armhl.
> > "x86_64-32" now for example is composed as "x32".
> >
> > Note that I am referring to the new name given for the architecture
> > that composes the packages or package names.  These are based on
> > Debian, which has more generic names for the architecture (see
> > https://wiki.debian.org/SupportedArchitectures).
> >
> > This implied making changes to the cross-compiler targets, in Qi,
> > and also now the Dragora ISO is composed using the new architecture
> > definition!.
>
> I see. But what exactly is the reason you changed that? Isn't "x86_64"
> the generic (and most neutral) name for this architecture?
>
> For example, the Intel Core 2 Duo processor I have in my main computer
> would run the "amd64" version of Dragora then.
>
> I think this way of naming that architecture has quite some potential
> for (unnecessary) confusion. But maybe you had some good reasons to
> rename things that way.

x86_64 is a bad to type name with a char that can cause problems, plus 
x86_64 is also the kernel architecture for x32.

> > - I have improved Dragora by adding new security features to the
> > x86_64 (amd64) architecture such as "stack clash protection" and
> > "CET protection", both now by default.
> >
> > I did the same for i586, but I still couldn't test it well since the
> > current version of busybox doesn't work with the new Musl "time_t".
> > There are patches to be applied to busybox, but I prefer to wait for
> > the new version containing these changes to be released while I work
> > on other areas of Dragora.
>
> Yeah, that sounds reasonable. And thanks for enhancing security, though
> I understand none of those two things. :)

Haha.  I don't have much either, but it's better to have them[1][2], I 
think.

[1] 
http://securingsoftware.blogspot.com/2017/12/stack-clash-protection-in-gcc.html

From [2] 
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html:

"Enable code instrumentation of control-flow transfers to increase 
program security by checking that target addresses of control-flow 
transfer instructions (such as indirect function call, function return, 
indirect jump) are valid. This prevents diverting the flow of control to 
an unexpected target. This is intended to protect against such threats 
as Return-oriented Programming (ROP), and similarly call/jmp-oriented 
programming (COP/JOP)."

Distributions like Fedora (and surely Redhat) are using these features.

> > - I improved all the scripts related to Dragora tools, Dragora init
> > system against shellcheck (see shellcheck.net).
>
> Shellcheck for the win!

And the installer, of course.  :-)

> > - I have almost all the issues reported in
> > https://notabug.org/dragora/dragora/issues **almost solved**.
> >
> > At the moment I had to leave the code enhancement to the Swap part
> > of the installer.  The idea is to make this part that can detect
> > multiple (previously enabled) Swap partitions and decide which one to
> > add to the fstab, one or more at the same time (via selection).  I
> > already implemented and tested this.  I have to do the same for
> > partitions that are not activated and you want to format them by
> > activating them.  I hope to apply the same concept that you can
> > format one or more partitions at the "same time" and add the
> > corresponding entries to the fstab.
> >
> > ... I have some other minor changes locally that will improve as the
> > project progresses.
>
> Sounds great.
>
> > The next step or steps are to continue adjusting the installer,
> > finish the Swap part and continue with the modification of the menus
> > and instructions to install packages.  This has to be re-adapted and
> > super tested in order to make a successful installation (since the
> > names of the packages have changed, it's a good time to take
> > advantage of this to simplify and improve the visual or menu part).
>
> Okay, how would testing this work? My guess is that you'd have to
> compile an internal pre-release image for testing because the beta1
> image wouldn't really work anymore.

I should send the ISO here, privately (at some link), so you can test 
it.  It is possible that everything will not work according to the plan 
I mentioned, Trinity may not work, still it would be good to have this 
ISO to see who can help.

> > Later on I plan to update everything, including the new version of
> > Trinity Desktop to see if it works well, I think we will be able to
> > see the new version then...
>
> Trinity would be really cool to have because there are not too many
> distributions offering it through the package manager and those who do
> are, I guess, quite different from what people interested in Dragora
> would like to use. It's especially hard to find a distribution that has
> Trinity in the repositories and does not use systemd, as far as I can 
> see.
>
> Also, when the release is ready, let's work out a nice release
> announcement and send it out to a couple of interested parties in order
> to really get the word out about Dragora.

I would appreciate any help here, since whenever I try to make an 
announcement, I arrive mentally exhausted.

> > P.S: I hope each of you is well!
>
> Yeah, I'm trying to Scheme it up in small daily doses here. :) Well, 
> and
> all the other stuff I do in my other life is going okay as well, no
> brick laying involved.

Cool, Scheme seems a good option to learn.  But now I'm kind of more 
into learning C.  :-)

> Enjoy your rest and all the best!

Thanks, I'm gonna need it.  The baby's sure to wake up at night wanting 
to hack.  ;-)