/mandos/release

To get this branch, use:
bzr branch http://bzr.recompile.se/loggerhead/mandos/release

« back to all changes in this revision

Viewing changes to overview.xml

  • Committer: Teddy Hogeborn
  • Date: 2015-08-10 07:34:37 UTC
  • mto: (237.7.594 trunk)
  • mto: This revision was merged to the branch mainline in revision 325.
  • Revision ID: teddy@recompile.se-20150810073437-3m8jgt13nqric6vf
Revert change to D-Bus API.

The D-Bus API signal CheckerCompleted is documented to provide a
wait(2) status value.  Since the server switched to using subprocess
to run checkers, it no longer has access to a wait(2) status value.  A
previous change to work around this made the D-Bus API incompatible.
Revert this change by constructing a fake wait(2) status value; this
keeps the D-Bus API stable.

* DBUS-API (CheckerCompleted): Revert incompatible change.
* mandos (ClientDBus.checker_callback): Construct fake wait(2) status.
* mandos-monitor (MandosClientWidget.checker_completed): Revert to
                                                         using
                                                         original API
                                                         with wait(2)
                                                         condition
                                                         value.

Show diffs side-by-side

added added

removed removed

Lines of Context:
overview.xml
8
8
  program in the initial <acronym>RAM</acronym> disk environment which
9
9
  will communicate with a server over a network.  All network
10
10
  communication is encrypted using <acronym>TLS</acronym>.  The
11
 
  clients are identified by the server using a TLS key; each client
12
 
  has one unique to it.  The server sends the clients an encrypted
13
 
  password.  The encrypted password is decrypted by the clients using
14
 
  a separate OpenPGP key, and the password is then used to unlock the
15
 
  root file system, whereupon the computers can continue booting
16
 
  normally.
 
11
  clients are identified by the server using an OpenPGP key; each
 
12
  client has one unique to it.  The server sends the clients an
 
13
  encrypted password.  The encrypted password is decrypted by the
 
14
  clients using the same OpenPGP key, and the password is then used to
 
15
  unlock the root file system, whereupon the computers can continue
 
16
  booting normally.
17
17
</para>