Re: GNOME 3.22.0 newstable tarballs due (and more) (responsible: mclasen)

[Bastien Nocera]

Great stuff, thanks!

> On 21 Sep 2016, at 21:21, Michael Catanzaro  wrote:
> 
>> On Tue, 2016-09-20 at 21:11 -0500, Michael Catanzaro wrote:
>> Matthias rebuilt the version set at least once today in order to pick
>> up stragglers. Not sure why your releases didn't get in; seems like
>> today's other releases didn't either. I'll let him answer.
> 
> Checking today, it did get in, yay! Looks like Matthias did another
> rebuild last night.
> 
> Michael
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.22.0 newstable tarballs due (and more) (responsible: mclasen)

[Michael Catanzaro]

On Tue, 2016-09-20 at 21:11 -0500, Michael Catanzaro wrote:
> Matthias rebuilt the version set at least once today in order to pick
> up stragglers. Not sure why your releases didn't get in; seems like
> today's other releases didn't either. I'll let him answer.

Checking today, it did get in, yay! Looks like Matthias did another
rebuild last night.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Testing for memory safety issues with Address Sanitizer

[Michael Catanzaro]

On Wed, 2016-09-21 at 16:14 +0200, Tobias Mueller wrote:
> Try LDFLAGS+=-lasan

==21260==ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it
with LD_PRELOAD.

> Another source of inconvenience is when compiling any library that
> GCC needs itself, like gnome-calculator does.
> Then, setting LD_PRELOAD=/usr/lib64/libasan.so worked for me.

For some reason, Fedora doesn't seem to have a libasan-devel package,
so there's no plain libasan.so. Really strange. I tried changing it to
libasan.so.3 in my jhbuildrc but actually couldn't figure out how to do
that; jhbuild is playing with LD_PRELOAD as well. :(

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME 3.22 released

[Matthias Clasen]

The GNOME Project is proud to announce the release of GNOME 3.22, "Karlsruhe".

This release brings comprehensive Flatpak support. GNOME Software can
install and update Flatpaks, GNOME Builder can create them, and the
desktop provides portal implementations to enable sandboxed applications.

Improvements to core GNOME applications include support for batch renaming
in Files, sharing support in GNOME Photos, an updated look for GNOME Software,
a redesigned keyboard settings panel, and many more.

For more information about the changes in GNOME 3.22, you can visit
the release notes:

 https://help.gnome.org/misc/release-notes/3.22/

GNOME 3.22 will be available shortly in many distributions. If you want
to try it today, you can use the openSUSE nightly live images which
include GNOME 3.22.

 https://www.gnome.org/getting-gnome/
 
http://download.opensuse.org/repositories/GNOME:/Medias/images/iso/?P=GNOME_Next*

To try the very latest developments in GNOME, you can also use the
VM disk images that are produced by the gnome-continuous build system.

 https://wiki.gnome.org/Projects/GnomeContinuous

If you are interested in building applications for GNOME 3.22, you can
use the GNOME 3.22 Flatpak SDK, which is available in the sdk.gnome.org
repository.

This six-month effort wouldn't have been possible without the whole
GNOME community, made of contributors and friends from all around the
world: developers, designers, documentation writers, usability and
accessibility specialists, translators, maintainers, students, system
administrators, companies, artists, testers and last, not least, users.
GNOME would not exist without all of you. Thank you to everyone!

This release was created at the first LAS GNOME conference in Portland,
Oregon. Thanks to the conference organizers for this lovely event!

Our next release, GNOME 3.24, is planned for March 2017. Until then,
enjoy GNOME 3.22!

The GNOME Release Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Testing for memory safety issues with Address Sanitizer

[Tobias Mueller]

Hi.

On Wed, Sep 21, 2016 at 08:17:03AM -0500, Michael Catanzaro wrote:
> undefined symbol: __asan_option_detect_stack_use_after_return
> 
> Is anything special needed for dlopened modules?
Try LDFLAGS+=-lasan

Another source of inconvenience is when compiling any library that
GCC needs itself, like gnome-calculator does.
Then, setting LD_PRELOAD=/usr/lib64/libasan.so worked for me.

Cheers,
  Tobi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.22.0 newstable tarballs due (and more) (responsible: mclasen)

[Murray Cumming]

On Di, 2016-09-20 at 19:06 -0500, Michael Catanzaro wrote:
> glibmm, [snip] gtkmm,

I generally don't do a .0 version of glib or gtkmm until the .0 version
of glib and gtk+ exists.

-- 
Murray Cumming
murr...@murrayc.com
www.murrayc.com



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Testing for memory safety issues with Address Sanitizer

[Philip Withnall]

Hi,

On Mon, 2016-09-19 at 12:03 +0200, Hanno Böck wrote:
> I recently reported a couple of bugs to GNOME-components that were
> easily discovered with a feature called Address Sanitizer (asan):
> https://bugzilla.gnome.org/show_bug.cgi?id=762417 (glib)
> https://bugzilla.gnome.org/show_bug.cgi?id=762493 (glib)
> https://bugzilla.gnome.org/show_bug.cgi?id=768441 (gnome-session)
> 
> The first two are out of bounds reads in glib that get triggered by
> running the test suite with "make check". The third is a buffer
> overflow in gnome-session that gets triggered on every startup.

Nice work!

> Things that could be done, by increasing complexity:
> 
> * Run the existing test suites with address sanitizer
> This could be mostly automated, it's usually as simple as doing
> something like:
> ./configure CFLAGS="-fsanitize=address -g -fno-common
> -U_FORTIFY_SOURCE" CXXFLAGS="-fsanitize=address -g -fno-common
> -U_FORTIFY_SOURCE" LDFLAGS="-fsanitize=address -g -fno-common
> -U_FORTIFY_SOURCE"
> make
> ASAN_OPTIONS="log_path=/var/log/asan/asan-error" make check

It’s something which would be good to have running as part of CI, along
with the other -fsanitize options (address, thread, leak, undefined) and
things like -D_FORTIFY_SOURCE=1.

Unfortunately, these flags are mostly mutually exclusive, which means that we’d 
need 5 new CI pipelines.

I guess the right approach is to set up a few more parallel instances of 
gnome-continuous, each running with different compiler options. I’ll have a 
play with that tomorrow. I guess eventually it could be integrated into 
gnome-continuous as a new set of tree suffixes.

> * Run GNOME itself and its applications with asan enabled.
> Test suites are fine, but they don't replace real testing, i.e.
> actually running the software.
> Ideally one would built the full software stack with address sanitizer
> enabled to find bugs both in the applications themselve and in
> libraries.

Automated tests complement manual testing, and require a lot less effort
over time. (While it would be lovely in theory, in practice, very few
maintainers are going to recompile each of their projects with 5 different
sets of compiler options and manually test every feature in the UI before a
release — that’s a huge amount of work.)

Enabling asan in the jhbuild configuration by default would be one option,
with the idea that people would then develop using it by default. However,
asan interferes with Valgrind, and I think that Valgrind is probably the
more useful tool to have working in a development environment like jhbuild.
Additionally, this means consciously prioritising asan over any other
-fsanitize or hardening flags (which is fine, but it is a tradeoff).

> * Use Fuzzing.
> This is especially interesting for everything that is parsing complex
> data formats.
> There has been a lot of improvement in fuzzing techniques lately and
> advanced fuzzing tools like american fuzzy lop or libfuzzer can greatly
> help in improving and securing code.
> 
> I have some introductions to these things on the fuzzing project
> webpage:
> https://fuzzing-project.org/tutorials.html

Not really related to asan, but good advice all the same. afl is pretty
amazing.

> I discussed this already with Tobias Mueller recently and he already
> started finding a couple of issues with asan:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=771607
> https://bugzilla.gnome.org/show_bug.cgi?id=771608
> https://bugzilla.gnome.org/show_bug.cgi?id=771609
> https://bugzilla.gnome.org/show_bug.cgi?id=771610
> https://bugzilla.gnome.org/show_bug.cgi?id=771612
> https://bugzilla.gnome.org/show_bug.cgi?id=771298
> https://bugzilla.gnome.org/show_bug.cgi?id=771289

I should reiterate that I think doing testing like this manually is a trap.
For this to be useful, it needs to be automated — that will rely on each
module having good test coverage, but that’s a good goal to aim for anyway.

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list