Add support for component agreements

This enables a lot of software to comply with the GDPR and also allows us to
show translated warning and EULA text to unsuspecting users.

3 files changed, 442 insertions, 0 deletions

diff --git a/data/tests/example-eula.metainfo.xml b/data/tests/example-eula.metainfo.xml
new file mode 100644
index 0000000..516b79e
--- /dev/null
+++ b/data/tests/example-eula.metainfo.xml
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Copyright 2018 Richard Hughes <richard@hughsie.com> -->
+
+<component type="desktop">
+  <id>org.gnome.Software</id>
+  <name>GNOME Software</name>
+  ...usual contents for a desktop app...
+  <metadata_license>CC0</metadata_license>
+  <agreement type="eula" version_id="1.0">
+    <agreement_section>
+      <description>
+        <p>
+          If it breaks, you get to keep both pieces.
+        </p>
+      </description>
+    </agreement_section>
+  </agreement>
+</component>
diff --git a/data/tests/example-gdpr.metainfo.xml b/data/tests/example-gdpr.metainfo.xml
new file mode 100644
index 0000000..2bac8fc
--- /dev/null
+++ b/data/tests/example-gdpr.metainfo.xml
@@ -0,0 +1,396 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Copyright 2018 Richard Hughes <richard@hughsie.com> -->
+
+<component type="general">
+  <id>org.fwupd.lvfs</id>
+  <name>Linux Vendor Firmware Service</name>
+  <metadata_license>CC0</metadata_license>
+
+  <agreement type="privacy" version_id="1.0">
+
+    <agreement_section type="introduction">
+      <name>Introduction</name>
+      <description>
+        <p>
+          We hold personal data about vendors, administrators, clients and other
+          individuals for a variety of purposes.
+          This policy sets out how we seek to protect personal data and ensure that
+          administrators understand the rules governing their use of personal data to
+          which they have access in the course of their work.
+          In particular, this policy requires that the Data Protection Officer (DPO) be
+          consulted before any significant new data processing activity is initiated to
+          ensure that relevant compliance steps are addressed.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="scope">
+      <name>Scope</name>
+      <description>
+        <p>
+          This policy applies to all users who have access to any of the personally
+          identifiable data.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="dpo">
+      <name>Who is responsible for this policy?</name>
+      <description>
+        <p>
+          As the Data Protection Officer, Richard Hughes
+          has overall responsibility for the day-to-day implementation of this policy.
+          The DPO is registered with the Information Commissioner’s Office (ICO) in the
+          United Kingdom as a registered data controller.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="processing">
+      <name>Fair and lawful processing</name>
+      <description>
+        <p>
+          We must process personal data fairly and lawfully in accordance with individuals’ rights.
+          This generally means that we should not process personal data unless the
+          individual whose details we are processing has consented to this happening,
+          or where such collection is unavoidable and/or considered pragmatic in the
+          context, e.g. logging the number of downloads of a particular file.
+        </p>
+        <p>
+          We do not consider an IP address to represent a single user (due to NAT or VPN use),
+          and as such metadata requests are not considered personal data using the draft GDPR guidelines.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="accuracy">
+      <name>Accuracy and relevance</name>
+      <description>
+        <p>
+          We will ensure that any personal data we process is accurate, adequate,
+          relevant and not excessive, given the purpose for which it was obtained.
+          We will not process personal data obtained for one purpose for any unconnected
+          purpose unless the individual concerned has agreed to this or would otherwise
+          reasonably expect this.
+          Individuals may ask that we correct inaccurate personal data relating to them.
+          If you believe that information is inaccurate you should inform the DPO.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="personal">
+      <name>Your personal data</name>
+      <description>
+        <p>
+          You must take reasonable steps to ensure that personal data we hold about
+          hardware vendors is accurate and updated as required.
+          For example, if your personal circumstances change, please update them using
+          the profile pages or inform the Data Protection Officer.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="security">
+      <name>Data security</name>
+      <description>
+        <p>
+          We keep personal data secure against loss or misuse.
+          Where other organisations process personal data as a service on our behalf,
+          the DPO will establish what, if any, additional specific data security
+          arrangements need to be implemented in contracts with those third party
+          organisations.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="storage">
+      <name>Storing data securely</name>
+      <description>
+        <p>
+        All data is stored electronically.
+        All documents and code are held on a locked LUKS partition with a password
+        adhering to security best practices.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="retention">
+      <name>Data retention</name>
+      <description>
+        <p>
+          We must retain personal data for no longer than is necessary.
+          What is necessary will depend on the circumstances of each case, taking into
+          account the reasons that the personal data was obtained, but should be
+          determined in a manner consistent with our data retention guidelines.
+          Anonymized user data (e.g. metadata requests) will be kept for a maximum of
+          5 years which allows us to project future service requirements and provide
+          usage graphs to the vendor.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="transfer">
+      <name>Transferring data internationally</name>
+      <description>
+        <p>
+          There are restrictions on international transfers of personal data.
+          We do not transfer personal data anywhere outside the EU without the approval
+          of the Data Protection Officer, unless required to do so by law.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="access-requests">
+      <name>Subject Access Requests</name>
+      <description>
+        <p>
+          Please note that under the Data Protection Act 1998, individuals are entitled,
+          subject to certain exceptions, to request access to information held about them.
+        </p>
+        <p>
+          On receiving a subject access request, we will refer that request immediately
+          to the DPO. We may ask you to help us comply with those requests.
+          Please also contact the Data Protection Officer if you would like to correct
+          or request information that we hold about you.
+          There are also restrictions on the information to which you are entitled under
+          applicable law.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="processing">
+      <name>Processing data in accordance with your rights</name>
+      <description>
+        <p>
+          We will never use identifiable vendor data for direct marketing purposes.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="transparency">
+      <name>Transparency of data protection</name>
+      <description>
+        <p>
+          Being transparent and providing accessible information to individuals about how
+          we will use their personal data is important for our project.
+        </p>
+        <p>
+          We will ensure any use of personal data is justified using at least one of
+          the conditions for processing and this had been specifically documented.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="consent">
+      <name>Consent</name>
+      <description>
+        <p>
+          The data that we collect is subject to active consent by the data subject.
+          This consent can be revoked at any time, but would end any vendor
+          relationship with the LVFS.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="portability">
+      <name>Data portability</name>
+      <description>
+        <p>
+          Upon request, a data subject should have the right to receive a copy of their
+          data in a structured format, typically an SQL export.
+          These requests should be processed within one month, provided there is no
+          undue burden and it does not compromise the privacy of other individuals.
+          A data subject may also request that their data is transferred directly to
+          another system. This is available for free.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="forgotten">
+      <name>Right to be forgotten</name>
+      <description>
+        <p>
+          A vendor may request that any information held on them is deleted or removed,
+          and any third parties who process or use that data must also comply with the request.
+          An erasure request can only be refused if an exemption applies.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="design">
+      <name>Privacy by design and default</name>
+      <description>
+        <p>
+          Privacy by design is an approach to projects that promote privacy and data
+          protection compliance from the start.
+          The DPO will be responsible for conducting Privacy Impact Assessments and
+          ensuring that all changes commence with a privacy plan.
+          When relevant, and when it does not have a negative impact on the data subject,
+          privacy settings will be set to the most private by default.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="audit">
+      <name>Data audit and register</name>
+      <description>
+        <p>
+          Regular data audits to manage and mitigate risks will inform the data register.
+          This contains information on what data is held, where it is stored,
+          how it is used, who is responsible and any further regulations or retention
+          timescales that may be relevant.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="breaches">
+      <name>Reporting breaches</name>
+      <description>
+        <p>
+          All users of the LVFS have an obligation to report actual or potential data
+          protection compliance failures. This allows us to:
+        </p>
+        <ul>
+          <li>Investigate the failure and take remedial steps if necessary</li>
+          <li>Maintain a register of compliance failures</li>
+          <li>
+            Notify the Supervisory Authority (SA) of any compliance failures that are
+            material either in their own right or as part of a pattern of failures
+          </li>
+        </ul>
+        <p>
+          Please refer to the DPO for our reporting procedure.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="monitoring">
+      <name>Monitoring</name>
+      <description>
+        <p>
+          Everyone who actively uses the LVFS must observe this policy.
+          The DPO has overall responsibility for this policy.
+          They will monitor it regularly to make sure it is being adhered to.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="consequences">
+      <name>Consequences of Failing to Comply</name>
+      <description>
+        <p>
+          We take compliance with this policy very seriously.
+          Failure to comply puts both you and us at risk.
+          The importance of this policy means that failure to comply with any requirement
+          may lead to disciplinary action under our procedures.
+          If you have any questions or concerns about anything in this policy,
+          do not hesitate to contact the DPO.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="detail-misc">
+      <name>Details: Firmware Vendor Information</name>
+      <description>
+        <p>
+          What: The hardware vendor name, password, GPG public key and content of original
+        uploaded firmware files..
+        </p>
+        <p>
+          Why colected: Secure authentication, to allow any possible future audit and to provide
+          authorised users access to signed firmware files.
+        </p>
+        <p>
+          Where stored: MySQL database on fwupd.org.
+        </p>
+        <p>
+          When copied: Backed up to off-site secure LUKS partition weekly.
+        </p>
+        <p>
+          Who has access: The hardware vendor (filtered by the QA group) and the DPO.
+        </p>
+        <p>
+          Wiped: When the vendor requests deletion of the user account.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="detail-misc">
+      <name>Details: Service Event Log</name>
+      <description>
+        <p>
+          What: IP address (unhashed) and REST method requested, along with any error.
+        </p>
+        <p>
+          Why colected: Providing an event log for checking what the various hardware vendors are
+          doing, or trying to do..
+        </p>
+        <p>
+          Where stored: MySQL database on fwupd.org.
+        </p>
+        <p>
+          When copied: Backed up to off-site secure LUKS partition weekly.
+        </p>
+        <p>
+          Who has access: The hardware vendor (filtered by the QA group) and the DPO.
+        </p>
+        <p>
+          Wiped: When the QA group is deleted.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="detail-misc">
+      <name>Details: Firmware Download Log</name>
+      <description>
+        <p>
+          What: IP address (hashed), timestamp, filename of firmware, user-agent of client.
+        </p>
+        <p>
+          Why colected: To know what client versions are being used for download, and to provide
+          a download count over time for a specific firmware file.
+        </p>
+        <p>
+          Where stored: MySQL database on fwupd.org.
+        </p>
+        <p>
+          When copied: Backed up to off-site secure LUKS partition weekly.
+        </p>
+        <p>
+          Who has access: The hardware vendor (filtered by the QA group) and the DPO.
+        </p>
+        <p>
+          Wiped: When the firmware is deleted.
+        </p>
+      </description>
+    </agreement_section>
+
+    <agreement_section type="detail-misc">
+      <name>Details: Firmware Reports</name>
+      <description>
+        <p>
+          What: Machine ID (hashed), failure string and checksum of failing file,
+          OS distribution name and version.
+        </p>
+        <p>
+          Why colected: Allows the hardware vendor to assess if the firmware update is working on
+        real hardware.
+        </p>
+        <p>
+          Where stored: MySQL database on fwupd.org.
+        </p>
+        <p>
+          When copied: Backed up to off-site secure LUKS partition weekly.
+        </p>
+        <p>
+          Who has access: The hardware vendor (filtered by the QA group) and the DPO.
+        </p>
+        <p>
+          Wiped: When the firmware is deleted.
+        </p>
+      </description>
+    </agreement_section>
+
+  </agreement>
+
+</component>
diff --git a/data/tests/example-remote.metainfo.xml b/data/tests/example-remote.metainfo.xml
new file mode 100644
index 0000000..8da5996
--- /dev/null
+++ b/data/tests/example-remote.metainfo.xml
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Copyright 2018 Richard Hughes <richard@hughsie.com> -->
+
+<component type="source">
+  <id>org.lvfs.stable-remote</id>
+  <name>Linux Vendor Firmware Service (stable firmware)</name>
+  <metadata_license>CC0</metadata_license>
+
+  <agreement version_id="1.0">
+    <agreement_section>
+      <name>Warning!</name>
+      <description>
+        <p>
+          The LVFS is a free service that operates as an independent legal
+          entity and has no connection with your distribution.
+          Your distributor may not have verified any of the firmware files for
+          compatibility with your system.
+          All firmware is provided only by the original equipment manufacturer.
+        </p>
+        <p>
+          Enabling this functionality is done at your own risk, so please do not
+          file issues with your distributor as they will not be able to help.
+        </p>
+      </description>
+    </agreement_section>
+  </agreement>
+
+</component>