Hello again! It’s time for the last (maybe) blog post about my gsoc.
My work on the GSoC project in the last weeks has focused on the integration of the new authorization library with the rest of kde. You can find all the code in the subversion at branches/work/kdelibs-libkauth and kdebase-libkauth.
A brief explaination of what I’ve done follows.
Hello again!
My gsoc project proceed very well. I’m happy to announce that the new kde authorization library is feature-complete and has been moved in kdereview. I’ve mailed kde-core-devel to ask feedback.
Now you can find the library at trunk/kdereview/libkauth.
Since the last blog post, I’ve added some new APIs and refined the existing. Now the API is completely documented (with doxygen).
I’ve added the cmake macros to help you create actions policies in a cross-platform way.
Now everything’s ready for the next step: extending KAction, KPushButton and other GUI elements to let developers to easily use the new API.
Bye bye 
Hello!!
The summer of code midterm evaluations arrived and so It’s time to blog about what I’ve done so far.
The new library implements an easy way to use the caller/helper pattern to perform privileged tasks without having to run the GUI as root. The authorization library is currently working well on Linux with the PolicyKit backend and the OS X backend is in progress.
The main features are:
You can download the code from the kde repository at playground/base/libkauth and to compile it you need Qt (of course) and polkit-qt, which is available from the repository at kdesupport/polkit-qt.
In the example/ subdirectory you’ll find some code that use the library. It’s a very stupid text editor that can open and save files to protected locations using the helper. I also provided a long-running action to show the use of asynchronous actions and actions termination.
An overview of the API follows, looking at the example application included.
Mi capita ogni tanto di battibeccare amichevolmente con qualche bravo amministratore unix sulla sensatezza delle impostazioni di default di Ubuntu riguardo agli utenti, le autenticazioni ecc…
Le convinzioni che vengono palesate (non solo da queste persone, ma in generale da chi non conosce il sistema) sono del tipo: “su ubuntu gli utenti normali possono fare quello che vogliono” oppure “chiunque può diventare root” o “basta sapere la password di un utente normale per diventare root”. Con questo post voglio dare una panoramica chiara su come funzionano le cose secondo le impostazioni di default di Ubuntu e chiarire le ragioni che stanno dietro a queste scelte tecniche.
A dopo il salto…
E’ con estrema gioia che annuncio su questo famosissimo blog l’allegra novella: sono stato accettato al Google Summer of Code 2009!
Per chi non lo sapesse, si tratta di un’iniziativa che google mette in piedi da qualche anno, per attirare studenti verso lo sviluppo di progetti open source. Quello che dovrò fare, assieme agli altri 1000 partecipanti, è scrivere codice per un importante progetto open source in cambio di alcune pecunie (parecchie in realtà) durante il periodo estivo (giugno-agosto).
Ognuno degli aspiranti GSoCers (come ci chiamano in gergo) ha dovuto presentare un piano di progetto su cosa voleva fare e in quali tempistiche, ed il team del rispettivo progetto (nel mio caso KDE) ha deciso quali accettare.
Il 23 aprile scorso è stata pubblicata la lista ufficiale degli studenti accettati. La lista degli studenti per KDE la potete trovare qui.
Cosa dovrò fare io? Il mio progetto ha a che fare (guardacaso) anche con il Mac, e in particolare dovrò scrivere una API multipiattaforma per l’autenticazione e l’autorizzazione degli utenti, per quelle applicazioni che necessitano di privilegi per svolgere il loro lavoro. Il backend per linux userà PolicyKit, uno standard di freedesktop già abbastanza affermato, mentre i backend per Mac e Windows useranno le API native dei rispettivi sistemi.
La specifica completa del mio lavoro la potete leggere in questo PDF. Si tratta del documento che ho spedito per la fase di selezione, sulla base del quale il team di KDE ha scelto di darmi fiducia.
Un ringraziamento speciale va a Dario Freddi, lo sviluppatore principale di polkit-qt nonchè colui che ha voluto farmi da mentor permettendomi di partecipare. Ringrazio anche Davide Bettio, che ha parlato di me a Dario. E grazie anche a tutti quanti già che ci siamo
Mi aspetta un’estate di programmazione a pieno ritmo (come tutte le precedenti del resto), e questa volta sarò pure pagato!! Evviva XD
Ecco dopo un po’ di pausa un altro post su questo frequentatissimo blog 
Ho pensato di fare una carrellata sui principali sistemi di sicurezza implementati in Mac OS X, dividendoli in varie parti per non appesantire troppo il discorso, perchè ci sono parecchi meccanismi nascosti eppure sempre in funzione di cui l’utente abituale non si accorge nemmeno, ma che contribuiscono a rendere OS X un sistema di cui fidarsi (il sistema di cui non fidarsi invece è….).
Inizio dalla madre di tutti i sistemi di sicurezza, ovvero il modello di permessi di Unix. Tutti sanno che Mac OS X è un sistema Unix, ma l’utente è raramente coinvolto nelle faccende di basso livello e quindi un po’ di chiarezza non fa male. Per i veterani di Unix questo articolo sembrerà veramente molto da newbie, ma viceversa un veterano di Mac OS X non è detto che debba sapere tutto questo per usare bene il sistema.
A dopo il salto.