Merge lp:~mir-team/mir/attestable-timestamps-server into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Alan Griffiths on 2015-09-17 |
| Approved revision: | 2942 |
| Merged at revision: | 2943 |
| Proposed branch: | lp:~mir-team/mir/attestable-timestamps-server |
| Merge into: | lp:mir |
| Diff against target: |
1375 lines (+951/-5) 32 files modified
CMakeLists.txt (+1/-0) cmake/ABICheck.cmake (+2/-1) debian/control (+28/-0) debian/libmircookie-dev.install (+3/-0) debian/libmircookie1.install (+1/-0) debian/mir-test-tools.install (+1/-0) include/cookie/mir/cookie_factory.h (+104/-0) include/cookie/mir_toolkit/cookie.h (+44/-0) include/server/mir/server.h (+12/-0) include/test/mir_test_framework/executable_path.h (+1/-0) src/CMakeLists.txt (+3/-0) src/cookie/CMakeLists.txt (+48/-0) src/cookie/cookie_factory.cpp (+161/-0) src/cookie/mircookie.pc.in (+11/-0) src/cookie/symbols.map (+9/-0) src/include/server/mir/default_server_configuration.h (+7/-1) src/include/server/mir/server_configuration.h (+5/-0) src/server/CMakeLists.txt (+2/-1) src/server/default_server_configuration.cpp (+21/-1) src/server/server.cpp (+17/-0) src/server/symbols.map (+2/-0) tests/acceptance-tests/CMakeLists.txt (+3/-0) tests/include/mir_test_framework/udev_environment.h (+26/-0) tests/integration-tests/CMakeLists.txt (+1/-0) tests/mir_test_framework/CMakeLists.txt (+4/-0) tests/mir_test_framework/executable_path.cpp (+13/-0) tests/mir_test_framework/udev_environment.cpp (+38/-1) tests/mir_test_framework/udev_recordings/CMakeLists.txt (+3/-0) tests/mir_test_framework/udev_recordings/laptop-keyboard-hello.evemu (+272/-0) tests/unit-tests/CMakeLists.txt (+2/-0) tests/unit-tests/test_mir_cookie.cpp (+105/-0) tools/update_package_abis.sh (+1/-0) |
| To merge this branch: | bzr merge lp:~mir-team/mir/attestable-timestamps-server |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Tyler Hicks (community) | Needs Fixing on 2015-10-30 | ||
| Brandon Schaefer (community) | Approve on 2015-09-17 | ||
| Andreas Pokorny (community) | Approve on 2015-09-17 | ||
| Alexandros Frantzis (community) | Approve on 2015-09-17 | ||
| Kevin DuBois (community) | Approve on 2015-09-17 | ||
| PS Jenkins bot | continuous-integration | Approve on 2015-09-17 | |
| Alan Griffiths | Approve on 2015-09-17 | ||
| Chris Halse Rogers | Approve on 2015-09-10 | ||
|
Review via email:
|
|||
Commit Message
server: Added a CookieFactory which generates macs for keyboard/motions events.
library: CookieFactory creates macs based on timestamp info
Description of the Change
Splitting most the server bits from here:
https:/
The main parts are:
CookieFactory library
Integration with the server (init the cookie factory by seeding it with a random key)
- 2911. By Alexandros Frantzis on 2015-09-08
-
platform: Move gl_bind_to_texture method from Buffer to mir::renderer:
:gl::TextureBin dable. Approved by Cemil Azizoglu, PS Jenkins bot, Kevin DuBois.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2911
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Brandon Schaefer (brandontschaefer) wrote : | # |
From the other review:
AFAICS libmircookie is only used by libmirserver.
What is the advantage to having a shared library over linking the code directly into libmirserver?
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2912
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2912
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2912. By Chris Halse Rogers on 2015-09-09
-
Remove unnecessary server wakeups from TimeoutApplicat
ionNotRespondin gDetector. We don't need to wake up when either
a) There are no active sessions, or
b) All sessions we're aware of are unresponsive.Approved by PS Jenkins bot, Alexandros Frantzis, Kevin DuBois.
| Alan Griffiths (alan-griffiths) wrote : | # |
+std::string mir_test_
+{
+ std::string bin_path = MIR_BUILD_
+ std::string share_path = MIR_INSTALL_
+
+ if (boost:
+ return bin_path;
+ else if (boost:
+ return share_path;
+
+ BOOST_THROW_
+}
Can this really be the right behaviour? An installed test binary looks in the location where it was built? Even though a developer may be making changes there to compare results with.
~~~~
+ char const* RANDOM_DEVICE_PATH = "/dev/random";
+ int const WAIT_SECONDS = 30;
...
+ int const MAX_WAIT = 4;
http://
~~~~
AFAICS libmircookie is only used by libmirserver.
What is the advantage to having a shared library over linking the code directly into libmirserver?
~~~~
/mir/tests/
int const MAX_WAIT = 4;
^
1 error generated.
| Brandon Schaefer (brandontschaefer) wrote : | # |
>
> +std::string mir_test_
> +{
> + std::string bin_path = MIR_BUILD_
> + std::string share_path = MIR_INSTALL_
> +
> + if (boost:
> + return bin_path;
> + else if (boost:
> + return share_path;
> +
> + BOOST_THROW_
> in standard search locations"));
> +}
>
> Can this really be the right behaviour? An installed test binary looks in the
> location where it was built? Even though a developer may be making changes
> there to compare results with.
I should check the share folder first. Other then that... I think its correct behaviour. We still want to be able to test it in a build directory. Unless I add an env variable that we set for the test it self. Let me know which one you would like!
>
> ~~~~
>
> + char const* RANDOM_DEVICE_PATH = "/dev/random";
> + int const WAIT_SECONDS = 30;
> ...
> + int const MAX_WAIT = 4;
>
> http://
> t_Names
>
I need to read through the coding standard for mir :). Use to compiz/unity7/nux.
> ~~~~
>
> AFAICS libmircookie is only used by libmirserver.
>
> What is the advantage to having a shared library over linking the code
> directly into libmirserver?
>
This is how it currently stands but we are planning on using this for the content hub as well. So best to keep it shared now, as it will be used by something else.
> ~~~~
>
> /mir/tests/
> 'MAX_WAIT' [-Werror,
> int const MAX_WAIT = 4;
> ^
> 1 error generated.
Thanks! Missed removing that.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2913
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
Sorry about the long list here, most of it is about fitting in with the design styles that have grown in Mir and you would not yet be familiar with. I've voted "Needs Fixing" but many of the points might be addressed by discussion.
~~~~
src/server/
There's a lot of code added here (to generate a seed) that probably doesn't belong in a translation unit that is about constructing the right objects to configure the system. I'd prefer to see it put in a separate file. (Is there any reason it can't be part of the new library?)
~~~~
+void fill_vector_
Could we not use a return value instead of an out parameter?
~~~~
+std::string mir_test_
+{
+ std::string share_path = MIR_INSTALL_
+ std::string bin_path = MIR_BUILD_
+
+ if (boost:
+ return share_path;
+ else if (boost:
+ return bin_path;
+
+ BOOST_THROW_
+}
Can this be right? A development test binary looks in the location where it would be installed? Even though a developer may be making changes to the version in the build path.
The older logic (based on the executable path) seems less surprising.
~~~~
+class CookieFactory
+{
+public:
+ CookieFactory(
+ ~CookieFactory() noexcept;
+
+ MirCookie timestamp_
+
+ bool attest_
+
+private:
+ class CookieImpl;
+ std::unique_
+};
What is the reason for preferring the Cheshire Cat idiom over Interface Class? This makes it far harder to substitute alternative implementations (e.g. for testing that cookies actually are validated when necessary).
I can also imagine a desire to provide a different verification model in a (hypothetical) downstream server.
~~~~~
+void mir::Server:
+{
+ verify_
+ self->cookie_
+}
It is a little surprising that this sets the cookie factory, not the secret. I can't immediately think of anything this breaks but...
Between this and the previous, I think this would fit better into Mir's design patterns if:
1. CookieFactory were an interface and CookieImpl a derived class.
2. the configuration point were override_
~~~~~
=== added file 'tests/
This reads more like a unit test
~~~~~
+ mir_discover_
The acceptance tests (before and after this MP) don't need libumockdev-
~~~~~
AFAICS the_cookie_
- 2913. By Cemil Azizoglu on 2015-09-10
-
Implement create_
guest_platform( ) function for mir-on-X. Approved by Alan Griffiths, PS Jenkins bot.
- 2914. By Andreas Pokorny on 2015-09-10
-
Add a parameter to select additional deb repositories to get the chroot packages
With this the script implementation switches from debootstrap to multistrap. .
Approved by Alan Griffiths, Alexandros Frantzis, PS Jenkins bot.
- 2915. By Alan Griffiths on 2015-09-10
-
scene, tests: ensure that clients can observe the changes they make to the display configuration. Fixes: https:/
/bugs.launchpad .net/bugs/ 1491937. Approved by Andreas Pokorny, Alexandros Frantzis, PS Jenkins bot.
- 2916. By Andreas Pokorny on 2015-09-10
-
Remove dispatchable from InputDevice and reorganise x11 input code
The dispatchable method in InputDevice was used to give the InputDeviceHub direct control over the wakeups from user input devices. Most libraries do not allow doing that on a per device level, so fulfilling that interface gets impractical.
Approved by PS Jenkins bot, Alexandros Frantzis.
| Brandon Schaefer (brandontschaefer) wrote : | # |
> Sorry about the long list here, most of it is about fitting in with the design
> styles that have grown in Mir and you would not yet be familiar with. I've
> voted "Needs Fixing" but many of the points might be addressed by discussion.
>
> ~~~~
>
No problem at all :), Thanks for going through in depth!
> src/server/
>
> There's a lot of code added here (to generate a seed) that probably doesn't
> belong in a translation unit that is about constructing the right objects to
> configure the system. I'd prefer to see it put in a separate file. (Is there
> any reason it can't be part of the new library?)
>
> ~~~~
This is true, Im not 100% sure why it cant be in the library it self. Ill have to talk to Chris about that.
>
> +void fill_vector_
>
> Could we not use a return value instead of an out parameter?
>
> ~~~~
Changed!
>
> +std::string mir_test_
> +{
> + std::string share_path = MIR_INSTALL_
> + std::string bin_path = MIR_BUILD_
> +
> + if (boost:
> + return share_path;
> + else if (boost:
> + return bin_path;
> +
> + BOOST_THROW_
> in standard search locations"));
> +}
>
> Can this be right? A development test binary looks in the location where it
> would be installed? Even though a developer may be making changes to the
> version in the build path.
>
> The older logic (based on the executable path) seems less surprising.
>
> ~~~~
Yes... Hmm so my overall thought here is do we need to always install the file to run the tests? Or should we ever be able to run the tests on a build directory? If we just want the test to run off the install location im 100% fine with that. All else I can think about is setting an env variable so we can run it to the build directory (and the test can set it).
Either way im happy to change it.
>
> +class CookieFactory
> +{
> +public:
> + CookieFactory(
> + ~CookieFactory() noexcept;
> +
> + MirCookie timestamp_
> +
> + bool attest_
> +
> +private:
> + class CookieImpl;
> + std::unique_
> +};
>
> What is the reason for preferring the Cheshire Cat idiom over Interface Class?
> This makes it far harder to substitute alternative implementations (e.g. for
> testing that cookies actually are validated when necessary).
>
> I can also imagine a desire to provide a different verification model in a
> (hypothetical) downstream server.
>
> ~~~~~
Not sure the reasoning here, Ill have to talk to Chris about it. Wouldnt be to hard to switch over to just an interface.
>
> +void mir::Server:
> +{
> + verify_
> + self->cookie_
> +}
>
> It is a little surprising that this sets the cookie factory, n...
- 2917. By Alexandros Frantzis on 2015-09-10
-
renderers: Move GL renderer specific files to their own directory.
Approved by Kevin DuBois, Alan Griffiths, PS Jenkins bot.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2914
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 2918. By Alan Griffiths on 2015-09-10
-
scene: Ensure that the active application can get the correct display configuration. Fixes: https:/
/bugs.launchpad .net/bugs/ 1493741. Approved by Chris Halse Rogers, Kevin DuBois, PS Jenkins bot.
- 2919. By Cemil Azizoglu on 2015-09-10
-
[tests] Enable some tests, originally implemented for KMS, on mir-on-X.
Approved by PS Jenkins bot.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2915
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2920. By Kevin DuBois on 2015-09-10
-
fix sbuild cross compilation failure by passing the compiler variables to the gtest/gmock sub-project instead of our toolchain file. Also allow for setting MIR_TARGET_MACHINE and MIR_GCC_VARIANT via cmake -DMIR_TARGET_
MACHINE= ... (previously it was had to be set in the environment) fixes: lp: #1493895. Fixes: https:/
/bugs.launchpad .net/bugs/ 1493895. Approved by Cemil Azizoglu, Alan Griffiths, PS Jenkins bot.
| Chris Halse Rogers (raof) wrote : | # |
> What is the reason for preferring the Cheshire Cat idiom over Interface Class?
> This makes it far harder to substitute alternative implementations (e.g. for
> testing that cookies actually are validated when necessary).
>
> I can also imagine a desire to provide a different verification model in a
> (hypothetical) downstream server.
libmircookie is going to be used by Content Hub; Mir will share the secret with CH, and then CH will be able to verify cookies sent to it (for copy/paste and drag/drop operations). This is why it's a split-out library.
As such, it's actively harmful for downstream servers to override the implementation, as multiple processes need to agree on the method to verify cookies.
As an added bonus feature, it also means that libmircookie can have an actual ABI that's stable even under mild code churn :).
> Can this be right? A development test binary looks in the location where it
> would be installed? Even though a developer may be making changes to the
> version in the build path.
>
> The older logic (based on the executable path) seems less surprising.
Yeah, I'd have the test look first in the bin dir and *then* in the system-install location.
> src/server/
>
> There's a lot of code added here (to generate a seed) that probably doesn't
> belong in a translation unit that is about constructing the right objects to
> configure the system. I'd prefer to see it put in a separate file. (Is there
> any reason it can't be part of the new library?)
I'd have no objections to it being in the new library.
Other comments:
+ * This is not in any way cryptographically secure. This DOES NOT provide security.
We should drop this bit of the comment.
Once the above are dealt with: approve.
We should probably add a debian/
| Chris Halse Rogers (raof) wrote : | # |
Oh, whitespace before '}':
362 + MirCookie cookie { timestamp, 0};
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2916
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2919
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2921. By Chris Halse Rogers on 2015-09-11
-
Allow clients to set their surface event handler up front.
Currently, in order to not miss events, a client has to set an event handler in their surface_created callback, and so cannot sensibly use mir_surface_
create_ sync(). Allow the callback to be set up-front on the MirSurfaceSpec, closing this race.
Approved by Alan Griffiths, Kevin DuBois, PS Jenkins bot.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2920
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
> > I can also imagine a desire to provide a different verification model in a
> > (hypothetical) downstream server.
>
> libmircookie is going to be used by Content Hub; Mir will share the secret
> with CH, and then CH will be able to verify cookies sent to it (for copy/paste
> and drag/drop operations). This is why it's a split-out library.
>
> As such, it's actively harmful for downstream servers to override the
> implementation, as multiple processes need to agree on the method to verify
> cookies.
Oh, I agree that within a UI stack it ought to be fixed. Just imagining that someone /could/ want a different implementation in a different stack.
> As an added bonus feature, it also means that libmircookie can have an actual
> ABI that's stable even under mild code churn :).
OK, that's an argument for a separate library. In fact, is it really something that will need to be released with every Mir release? Or should it be a separate project?
BTW this last argument doesn't address the "Cheshire Cat vs Interface" point. The ABI could easily be:
std::unique_
std::unique_
- 2922. By Daniel van Vugt on 2015-09-11
-
Log more GL information. Especially to the super-useful extensions lists.
Approved by Kevin DuBois, Alan Griffiths, PS Jenkins bot.
| Alan Griffiths (alan-griffiths) wrote : | # |
> > === added file 'tests/
> >
> > This reads more like a unit test
> >
> > ~~~~~
> test_cookie_factory sound any better? (Im bad at names)
You misunderstand, I mean the test body reads like a unit test, not a test of the system.
| Brandon Schaefer (brandontschaefer) wrote : | # |
O yeah sorry, I was planning on moving all those tests to unit tests in the client code ... but i should do that now and save on diff +/- :)
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2921
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2923. By Kevin DuBois on 2015-09-11
-
use python3:any instead of just python3. Averts sbuild setup failure.
fixes: lp: #1494317. Fixes: https://bugs.launchpad .net/bugs/ 1494317. Approved by PS Jenkins bot, Alan Griffiths, Cemil Azizoglu.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2922
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2924. By Cemil Azizoglu on 2015-09-11
-
[tests] Unrestrict some common tests from being run for the x11 platform.
Approved by Alan Griffiths, PS Jenkins bot.
- 2925. By Cemil Azizoglu on 2015-09-11
-
[mir-on-X] Add platform specific options for the "display" size. .
Approved by PS Jenkins bot, Alexandros Frantzis, Alan Griffiths.
- 2926. By Alan Griffiths on 2015-09-11
-
client: tidy up some ugly whitespace.
Approved by PS Jenkins bot, Kevin DuBois.
- 2927. By Alan Griffiths on 2015-09-14
-
Have the ptest target fail if tests fail. Fixes: https:/
/bugs.launchpad .net/bugs/ 1454250. Approved by Daniel van Vugt, PS Jenkins bot.
- 2928. By Alan Griffiths on 2015-09-14
-
tests: Fix race condition in test setup. Fixes: https:/
/bugs.launchpad .net/bugs/ 1494663. Approved by Daniel van Vugt, PS Jenkins bot.
| Alan Griffiths (alan-griffiths) wrote : | # |
+namespace mir
+{
...
+class CookieFactory
...
+std::vector<
We reserve the general mir namespace for system setup. These could be in a "cookie" namespace.
~~~~
+class CookieFactory
+{
+public:
+ CookieFactory(
+ ~CookieFactory() noexcept;
+
+ MirCookie timestamp_
+
+ bool attest_
+
+private:
+ class CookieImpl;
+ std::unique_
+};
I'm still not convinced we should prefer the Cheshire Cat idiom (over Interface Class) here, but if we are taking this approach then impl should be const.
~~~~
+std::string mir_test_
+{
+ std::string bin_path = MIR_BUILD_
+ std::string share_path = MIR_INSTALL_
+
+ if (boost:
+ return bin_path;
+ else if (boost:
+ return share_path;
+
+ BOOST_THROW_
+}
Can this really be the right behaviour? An installed test binary looks in the location where it was built? Even though a developer may be making changes there?
The older logic (based on the executable path) seems less surprising.
~~~~
+ CookieFactory(
This will throw if the secret is too small, but the behaviour and minimum size is not documented anywhere.
I suggest providing a static class member (minimum_
| Alan Griffiths (alan-griffiths) wrote : | # |
Is libmircookie really something that will need to be released in sync with every Mir release? Or should it be a separate project?
~~~~
+std::vector<
Could be:
CookieFactory:
~~~~
+void mir::Server:
+{
+ verify_
+ self->cookie_
+}
It is a little surprising that this sets the cookie factory, not the secret.
- 2929. By Cemil Azizoglu on 2015-09-14
-
Unrestrict yet more tests for x11.
Approved by Alan Griffiths, Alexandros Frantzis, PS Jenkins bot.
- 2930. By Alexandros Frantzis on 2015-09-14
-
renderers: Remove redundant GL prefix from gl renderer classes.
Approved by PS Jenkins bot, Alan Griffiths.
- 2931. By Kevin DuBois on 2015-09-14
-
integration test: a bit of groundwork preparing the BufferScheduling integration test for integration with the new classes.
Approved by PS Jenkins bot, Alan Griffiths, Andreas Pokorny, Alexandros Frantzis.
| Brandon Schaefer (brandontschaefer) wrote : | # |
> Is libmircookie really something that will need to be released in sync with
> every Mir release? Or should it be a separate project?
I dont have a clear answer for this one. I just imagine since the project is pretty small it makes it easier to keep it in lp:mir atm? Will have to poke raof about that one.
>
> ~~~~
>
> +std::vector<
>
> Could be:
>
> CookieFactory:
>
I had this at first, but switched up because one of the primary use-cases for CookieFactory is when you've shared the secret with another process, which you can't do if you've called CookieFactory(
> ~~~~
>
> +void mir::Server:
> +{
> + verify_
> + self->cookie_
> +}
>
> It is a little surprising that this sets the cookie factory, not the secret.
I think this function should just be renamed to initialize_
| Brandon Schaefer (brandontschaefer) wrote : | # |
> +namespace mir
> +{
> ...
> +class CookieFactory
> ...
> +std::vector<
>
> We reserve the general mir namespace for system setup. These could be in a
> "cookie" namespace.
>
> ~~~~
Done.
>
> +class CookieFactory
> +{
> +public:
> + CookieFactory(
> + ~CookieFactory() noexcept;
> +
> + MirCookie timestamp_
> +
> + bool attest_
> +
> +private:
> + class CookieImpl;
> + std::unique_
> +};
>
> I'm still not convinced we should prefer the Cheshire Cat idiom (over
> Interface Class) here, but if we are taking this approach then impl should be
> const.
>
> ~~~~
Move to an NVI idiom:
http://
>
> +std::string mir_test_
> +{
> + std::string bin_path = MIR_BUILD_
> + std::string share_path = MIR_INSTALL_
> +
> + if (boost:
> + return bin_path;
> + else if (boost:
> + return share_path;
> +
> + BOOST_THROW_
> in standard search locations"));
> +}
>
> Can this really be the right behaviour? An installed test binary looks in the
> location where it was built? Even though a developer may be making changes
> there?
>
> The older logic (based on the executable path) seems less surprising.
>
> ~~~~
Not sure what the correct answer is here. What would be the best solution?
>
> + CookieFactory(
>
> This will throw if the secret is too small, but the behaviour and minimum size
> is not documented anywhere.
>
> I suggest providing a static class member (minimum_
> documenting the requirement.
Done.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2925
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2932. By Alan Griffiths on 2015-09-15
-
scene: Recent changes to display management mean the IPC thread blocks during display configuration changes. Avoid blocking for sessions that don't have focus as they don't actually "own" the display.
Approved by Kevin DuBois, Alexandros Frantzis, PS Jenkins bot.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2925
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
> > +std::vector<
> >
> > Could be:
> >
> > CookieFactory:
> >
>
> I had this at first, but switched up because one of the primary use-cases for
> CookieFactory is when you've shared the secret with another process, which you
> can't do if you've called CookieFactory(
I was thinking two constructors would be:
explicit CookieFactory(
explicit CookieFactory(
But I take your point - you need access to the "random data" to share the secret.
| Alan Griffiths (alan-griffiths) wrote : | # |
> > Is libmircookie really something that will need to be released in sync with
> > every Mir release? Or should it be a separate project?
>
> I dont have a clear answer for this one. I just imagine since the project is
> pretty small it makes it easier to keep it in lp:mir atm? Will have to poke
> raof about that one.
A further thought, the header is dependent on MirCookie (introduced here into include/
As we're introducing this dependency on mircommon, could we just put the code into libmircommon and not a separate library?
Or should MirCookie be defined in libmircookie-dev and not libmircommon-dev?
| Alan Griffiths (alan-griffiths) wrote : | # |
+#include <nettle/hmac.h>
...
+ struct hmac_sha1_ctx ctx;
Surely we don't want to introduce this dependency to user code? (See [1].)
There is no point in this class heirarchy if you are putting the derived class definition in the same header.
An option to consider here would the Named Constructor Idiom.
~~~~
+// Using the NVI Idiom
Nobody takes NVPI seriously - it is a solution in search of a problem.
The principle options to consider are Interface and Cheshire Cat (a.k.a. Pimpl). For a comparison of the different options see[2].
~~~~~
+ CookieFactoryNe
This will throw if the secret is too small, but the behaviour and minimum size is not documented in a doc comment on the function. (Having a non-doc comment in the private section of the class doesn't help the user.)
(But as I don't think this class should be made public anyway the documentation should go on the corresponding factory function.)
~~~~
> > The older logic (based on the executable path) seems less surprising.
> >
> > ~~~~
>
> Not sure what the correct answer is here. What would be the best solution?
I think to first check relative to the executable path (as it did before this MP), then to check the install location.
E.g. if running from a build directory it should pick up the one from e.g. <build>
~~~~
[1] http://
[2] http://
- 2933. By Alexandros Frantzis on 2015-09-15
-
renderers: Publish GL renderer development files.
Approved by PS Jenkins bot.
- 2934. By Alan Griffiths on 2015-09-15
-
tests: MesaBufferInteg
ration tries to load configuration options for platforms it doesn't use. Fixes: https:/ /bugs.launchpad .net/bugs/ 1495459. Approved by PS Jenkins bot, Alexandros Frantzis, Kevin DuBois.
- 2935. By Alan Griffiths on 2015-09-15
-
tests: delete unused TestingProcessM
anager and --tests- use-real- graphics. Approved by PS Jenkins bot, Alexandros Frantzis, Kevin DuBois.
- 2936. By Kevin DuBois on 2015-09-15
-
compositor: provide for setting a scale on the BufferStream. This separates the physical buffer size (how many pixels in the buffer) from the logical size (how big the buffers are composited onscreen).
Approved by Alan Griffiths, Alberto Aguirre, PS Jenkins bot.
| Brandon Schaefer (brandontschaefer) wrote : | # |
> +#include <nettle/hmac.h>
> ...
> + struct hmac_sha1_ctx ctx;
>
> Surely we don't want to introduce this dependency to user code? (See [1].)
>
> There is no point in this class heirarchy if you are putting the derived class
> definition in the same header.
>
> An option to consider here would the Named Constructor Idiom.
Done.
>
> ~~~~
>
> +// Using the NVI Idiom
>
> Nobody takes NVPI seriously - it is a solution in search of a problem.
>
> The principle options to consider are Interface and Cheshire Cat (a.k.a.
> Pimpl). For a comparison of the different options see[2].
>
> ~~~~~
Done.
>
> + CookieFactoryNe
>
> This will throw if the secret is too small, but the behaviour and minimum size
> is not documented in a doc comment on the function. (Having a non-doc comment
> in the private section of the class doesn't help the user.)
>
> (But as I don't think this class should be made public anyway the
> documentation should go on the corresponding factory function.)
>
> ~~~~
Done.
>
> > > The older logic (based on the executable path) seems less surprising.
> > >
> > > ~~~~
> >
> > Not sure what the correct answer is here. What would be the best solution?
>
> I think to first check relative to the executable path (as it did before this
> MP), then to check the install location.
>
> E.g. if running from a build directory it should pick up the one from e.g.
> <build>
>
> ~~~~
Done.
>
> [1] http://
>
> [2] http://
Thanks! Those were good reads. If you've more articles, I would be more then happy to read :).
| Brandon Schaefer (brandontschaefer) wrote : | # |
> > > Is libmircookie really something that will need to be released in sync
> with
> > > every Mir release? Or should it be a separate project?
> >
> > I dont have a clear answer for this one. I just imagine since the project is
> > pretty small it makes it easier to keep it in lp:mir atm? Will have to poke
> > raof about that one.
>
> A further thought, the header is dependent on MirCookie (introduced here into
> include/
> dependent on libmircommon-dev.
>
> As we're introducing this dependency on mircommon, could we just put the code
> into libmircommon and not a separate library?
>
> Or should MirCookie be defined in libmircookie-dev and not libmircommon-dev?
Well I dont see why it couldnt be defined in libmircookie-dev. I think *if* we keep libmircookie-dev we should move the MirCookie into it (unless Im missing something for why this isnt possible). If we move to libmircommon-dev then we'll keep it :).
Need to talk with RAOF about it as well
- 2937. By Alan Griffiths on 2015-09-15
-
tests: remove "--tests-
use-real- graphics" option that doesn't work and isn't getting fixed. Fixes: https:/ /bugs.launchpad .net/bugs/ 1221373, https:/ /bugs.launchpad .net/bugs/ 1373212. Approved by Kevin DuBois, PS Jenkins bot, Alexandros Frantzis, Andreas Pokorny.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2927
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2928
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2929
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2928
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2931
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
+class CookieFactory
...
Should delete copy constructor and assignment.
~~~~
+ static unsigned const minimum_
1. Ought to be public, so that it can be accessed by client code.
2. Not providing the value in the header allows it to be changed without breaking ABI, but it would probably be more convenient for users to have the value visible.
~~~~
+ * Contruction function used to create a CookieFactory. The secret size must be
+ * greater then minimum_secret_size otherwise an expection will be thrown
...
+ * Contruction function used to create a CookieFactory as well as a secret.
+ * The secret size must be greater then minimum_secret_size otherwise an expection will be thrown
s/greater then/no less than/
~~~~
+/**
+* Checks entropy exists on the system, then fills in a vector with random numbers
+* up to size.
+*
+* \param [in] size The number of random numbers to generate.
+* \return A filled in vector with random numbers up to size
+*/
+std::vector<
Not needed in the API
~~~~
+unsigned const min_secret_size{8};
This isn't needed, minimum_secret_size should be initialized directly.
~~~~~
+namespace
+{
+ unsigned const secret_size{64};
+}
There ought to be a guarantee (e.g. a static assert) that this is greater than CookieFactory:
~~~~
+TEST(MirCookie
+{
+ std::vector<
+ EXPECT_THROW({
+ auto factory = mir::cookie:
+ }, std::logic_error);
+}
OK, but it is better to test the "off by one" case. I.e. CookieFactory:
~~~~
There are missing tests:
1. create(unsigned secret_size, std::vector<
This should be tested to check that a secret of the right size is saved, and that it throws if too small a size is requested.
2. get_random_
*If* this is in the API there should be corresponding tests.
~~~~
+MIR_COOKIE_1 {
+ global:
+ extern "C++" {
+ mir::cookie:
+ mir::cookie:
+ mir::cookie:
+ mir::cookie:
+ mir::cookie:
+ mir::cookie:
+ };
+ local: *;
+};
The only functions that need to be exported are mir::cookie:
| Alan Griffiths (alan-griffiths) wrote : | # |
Just a bit of musing, not anything that requires action:
The create functions could be:
std::unique_
std::unique_
That might be more convenient for code that doesn't care about the secret size. There could also be other variants:
std::unique_
Which would support user code that just does:
auto const cf = CookieFactory:
Maybe not an important use case?
~~~~
It could also be convenient to include a definition of Secret:
using Secret = std::vector<
and use that in both the interface and user code.
- 2938. By Alexandros Frantzis on 2015-09-16
-
renderers,
platforms: Move public headers to top-level include directory structure. Approved by Alan Griffiths, PS Jenkins bot, Kevin DuBois.
- 2939. By Alan Griffiths on 2015-09-16
-
tests: Delete unused TestingClientCo
nfiguration. Approved by PS Jenkins bot, Alexandros Frantzis.
| Alan Griffiths (alan-griffiths) wrote : | # |
+TEST(MirCookie
+{
+ uint64_t timestamp = 23;
+ unsigned secret_size = 64;
+ std::vector<
+
+ auto factory = mir::cookie:
+ auto cookie = factory-
+
+ EXPECT_
+}
Not unreasonable, but I was actually thinking of...
uint64_t timestamp = 23;
unsigned secret_size = 64;
std:
auto const source_factory = mir::cookie:
auto const sink_factory = mir::cookie:
auto cookie = source_
EXPECT_
Which as one of the use cases we intend to support is something we should be testing.
| Alan Griffiths (alan-griffiths) wrote : | # |
For me, this is the remaining blocker:
> > > > Is libmircookie really something that will need to be released in sync
> > with
> > > > every Mir release? Or should it be a separate project?
> > >
> > > I dont have a clear answer for this one. I just imagine since the project
> is
> > > pretty small it makes it easier to keep it in lp:mir atm? Will have to
> poke
> > > raof about that one.
> >
> > A further thought, the header is dependent on MirCookie (introduced here
> into
> > include/
> > dependent on libmircommon-dev.
> >
> > As we're introducing this dependency on mircommon, could we just put the
> code
> > into libmircommon and not a separate library?
> >
> > Or should MirCookie be defined in libmircookie-dev and not libmircommon-dev?
>
> Well I dont see why it couldnt be defined in libmircookie-dev. I think *if* we
> keep libmircookie-dev we should move the MirCookie into it (unless Im missing
> something for why this isnt possible). If we move to libmircommon-dev then
> we'll keep it :).
>
> Need to talk with RAOF about it as well
| Alan Griffiths (alan-griffiths) wrote : | # |
It would be good for cookie clients to have a narrow, stable API.
To which end we should keep libmircookie as a separate project and make it independent of libmircommon-dev.
| Brandon Schaefer (brandontschaefer) wrote : | # |
> It would be good for cookie clients to have a narrow, stable API.
>
> To which end we should keep libmircookie as a separate project and make it
> independent of libmircommon-dev.
Done. Is it fine to keep the entire mir cookie project inside lp:mir or should a new project be created?
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2932
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
On Wednesday, 16 September 2015 20:47:24 BST, Brandon Schaefer wrote:
>> It would be good for cookie clients to have a narrow, stable API.
>>
>> To which end we should keep libmircookie as a separate project
>> and make it
>> independent of libmircommon-dev.
>
> Done. Is it fine to keep the entire mir cookie project inside
> lp:mir or should a new project be created?
Fine in mir tree. (For now anyway)
--
Alan Griffiths. +44 (0)798 9938 758
Octopull Limited. http://
- 2940. By Cemil Azizoglu on 2015-09-16
-
Compatibility overloads for old-style make_event functions.
Approved by PS Jenkins bot, Kevin DuBois.
| Brandon Schaefer (brandontschaefer) wrote : | # |
Hmm the only issue im not 100% sure about now. Is how we are going to expose the MirCookie to the mir_toolkit C api. I suppose Ill need to create a C api for the CookieFactory just to hold the MirCookie?
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2934
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2935
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2936
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
- 2941. By Alan Griffiths on 2015-09-17
- 2942. By Alan Griffiths on 2015-09-17
-
Fix include order & path
| Alan Griffiths (alan-griffiths) wrote : | # |
Pushed trivial fixes:
1. src/CMakeLists.txt to build cookie independently of any other Mir code
2. include/
3. include/
| Alan Griffiths (alan-griffiths) wrote : | # |
NB I think the server API needs extending to retrieve the generated secret, but that can come in the next MP.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2942
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Kevin DuBois (kdub) wrote : | # |
+ static std::unique_
+ unsigned secret_size = 2 * minimum_
+ static std::unique_
http://
not too flummoxed by that, the rest lgtm
| Alexandros Frantzis (afrantzis) wrote : | # |
Looks good.
Not blocking, but I find the following API simpler to understand:
create_
create_
Secret secret();
Of course, with this API the secret is no longer really "secret" (i.e. internal to the class), but I don't think it matters. If one has access to the class, then it doesn't really matter if one also has the secret (for our use cases at least).
| Andreas Pokorny (andreas-pokorny) wrote : | # |
Overall looks good for me.
This has changed quite a bit since the last time. When do we need override_
nit :+ 470 braces of lambda functor..
| Brandon Schaefer (brandontschaefer) wrote : | # |
> Looks good.
>
> Not blocking, but I find the following API simpler to understand:
>
> create_
> create_
> Secret secret();
>
> Of course, with this API the secret is no longer really "secret" (i.e.
> internal to the class), but I don't think it matters. If one has access to the
> class, then it doesn't really matter if one also has the secret (for our use
> cases at least).
A main use of the API is to share the secret around once its been created. So we need to be able to expose the secret on creation so we can share it with another factory.
| Brandon Schaefer (brandontschaefer) wrote : | # |
> Overall looks good for me.
>
> This has changed quite a bit since the last time. When do we need
> override_
>
This will be used in the client side of things. Not a perfect split from server/client but it will be used :).
> nit :+ 470 braces of lambda functor..
| Tyler Hicks (tyhicks) wrote : | # |
Hello - A review from the security team was requested and I've started to look at the code. However, I feel like I'm missing a lot of context from the greater design. It seems like this is only the very low-level building blocks needed by the greater design.
1) Does any documentation exist on the design? Thomas spoke with us about potential high-level designs months ago and I roughly understand which direction you all chose but this HMAC design was not one that we discussed at that time.
2) How will content-hub register itself with Mir? What's the flow of cookies between Mir, the foreground app, and content-hub during copy and paste events?
3) What prevents malicious apps from attempting to brute force cookies? I don't see any type of penalty implementation for repeated, bad guesses. Is content-hub expected to implement that?
| Chris Halse Rogers (raof) wrote : | # |
1) The copy/paste doc is at https:/
2) The design is for content-hub to share a secret with Mir, and each construct their own instance of CookieFactory from that secret. Content-hub does not need to register itself with Mir. The copy/paste doc has some cookie flow examples.
3) The Mir calls which accept a MirCookie¹ will disconnect any client that submits an invalid cookie. Content-hub should probably do the same. Would it be better to (a) document that any attestation failure should be fatal to the client, and (b) rename “bool attest_
¹: Here's an example: https:/
| Tyler Hicks (tyhicks) wrote : | # |
1) Thanks! The copy/paste doc helps a lot but it lacks implementation details. For example, "secret" isn't mentioned anywhere in the document. It does get me closer to understanding the design.
2) I'm confused by the "Content-hub does not need to register itself with Mir" bit since content-hub must share a secret with Mir and then Mir's CookieFactory is constructed from that secret. How does Mir know that the CookieFactory that it constructed was done so with a secret from Content-hub and not some other process?
3) If Mir disconnects a client that submits an invalid cookie, what prevents the client from reconnecting and submitting another invalid cookie?
- Documenting that any attestation failure should be fatal to the client would be a good thing as long as a reconnecting is expensive.
- IIUC, assert_timestamp() is in the address space of the client, correct? If so, throwing an exception on failure would do no good because a malicious client could link against a modified library that doesn't throw an exception.
| Chris Halse Rogers (raof) wrote : | # |
1, 2) Yeah, that bit of the design is unspecified. I was assuming that we'd either go for:
a) A parent process of unity8 and content-hub generates a secret and fd-passes it to both, or
b) Unity8 and content-hub share a file readable only by them, or
c) content-hub is started by unity8 and gets the secret fd-passed to it.
I'm not sufficiently familiar with the global design to know which one is most appropriate.
3) Unity8 only allows one connection per client. Actually, that's a lie; Unity8 effectively allows any client to connect to it, but in *theory* Unity8 only allows one connection per client. In theory, unity8 only allows applications started by upstart-app-launch and only allows one connection per launch, but in practice it allows anything that has --desktop-
So reconnection *should* be expensive, but currently isn't.
assert_timestamp() is in the server's address space; the secret required to assert a timestamp isn't available in the client address space.
| Tyler Hicks (tyhicks) wrote : | # |
1, 2) Ok, I'll follow up with tvoss on that aspect of the design.
3) We could probably do something as simple as adding a penalty delay after each failed attest attempt, before disconnecting the client.
Note that I also included a couple inline questions.
| Chris Halse Rogers (raof) wrote : | # |
3) It'd be reasonably complex to add a penalty delay after a failed attest attempt, but possible. It's much simpler for us to just disconnect the client.
Replies inline.
| Tyler Hicks (tyhicks) wrote : | # |
One more inline comment...
| Chris Halse Rogers (raof) wrote : | # |
Replies also inline.

FAILED: Continuous integration, rev:2909 jenkins. qa.ubuntu. com/job/ mir-ci/ 4825/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/3868/ console jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/2775/ console jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/3814/ console jenkins. qa.ubuntu. com/job/ mir-wily- amd64-ci/ 974/console jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 3814/console
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/4825/ rebuild
http://