Yes, we did it again! As every year FOSDEM is really inspiring for us, bringing important ideas and new solutions.
In this talk a fork of the original syslog-ng project was presented. In this fork automatic signing of every incoming log was implemented inside the core of the application enabling secure logging of every action performed on the system.
The particularity of this implementation highlighted both the encryption and signing of every single log entry/level using every time a different key. In addition, in order to prevent an attacker that compromises completely the system (root) to alter the logs and regenerate all the encryption and signing (blockchain) in order to hide himself only the last key used to encrypt the immediate successive log is stored on the system.
The process of releasing software is something that needs to be done in order to deliver software to customers, but is often something that can be very time-consuming, repetitive and also error-prone. In this talk OpenStack presented the automation that they developed in order to make the release process smooth and fast.
Besides the specific tools that are used in order to achieve the automation, the key idea that this talk conveyed is that by a proper use semantic versioning, everything that goes from the end of the development to the delivery of the software can be automated. Which means that stable branches and tags can be automatically managed, software automatically validated and deployed by CI tools, and also documentation automatically updated.
If you are a GO developer that loves to optimize your code by understanding how it is translated by the GO compiler, if you need to do some reverse engineering or you simply want to contribute to the GO project development, the
go buildcommand can help you a lot.
go build command offers some functionalities that allow you to see the complete logs of the process that transforms your go code into an executable program. The
-x option for example, prints out every istruction done from the compiler and the linker.
Inside these logs you can find also the path where you can find all the temporary files (*.AST, *.SSA) in which your code is converted during every step of the whole process. If want to go to see what is the content of those files you need to specify to the compiler to not delete them after the build is completed. To do so you need to specify
Please keep in mind that the go compiler caches all the info to build the code so if you want to force the compiler to redo every instruction everytime you run it, you need to add also the
The compiler first converts the go code into go assembly, that is an intermediate step in the creation of the binary code.
If you want to know how a specific instruction is translated, you can run the go build command with the
This option tells to the compiler to print out every line of assembly code it translates. For each instruction the compiler prints out also the relative line of the go source code file, so also if you are not familiar with assembly, you can esily find what’s going on.
Furthermore, if you find difficult to understand the assembly intermediate code in the output of go build command, there is another functionality of the go compiler that can be activated by setting an environment variable before to run the build.
In this variable you can specify the name of the function you want to analyze. The variable name is
GOSSAFUNC (go SSA function).
When the compiler finds this environment variable set to a valid function name, it dumps the SSA code generation instructions into an HTML file that allows you to read the compilation in a very interesting and interactive way from a common web browser.