Update content
This commit is contained in:
parent
92b5419011
commit
364d934442
|
|
@ -11,7 +11,9 @@
|
|||
- [Groups](./groups.md)
|
||||
- [Cwtch UI](./ui.md)
|
||||
- [Profile Encryption & Storage](./profile_encryption_and_storage.md)
|
||||
- [Cwtch Server](./server.md)
|
||||
- [Android Service](./android.md)
|
||||
- [Message Overlays](./overlays.md)
|
||||
- [Cwtch Servers](./server.md)
|
||||
- [Development](./development.md)
|
||||
- [Deployment](./deployment.md)
|
||||
- [References](./references.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
# Android Service
|
||||
|
||||
(Currently under active development, will be documented here once it has been merged into trunk)
|
||||
|
|
@ -23,7 +23,7 @@ Once derived from the key derivation function \\(\mathrm{KDF}\\\) the key
|
|||
\\(k\\) is set *on* the connection, meaning the authentication app doesn't
|
||||
do the encryption or decryption explicitly.
|
||||
|
||||
Also the concatenation of parts of the 3DH exchange is strictly ordered:
|
||||
The concatenation of parts of the 3DH exchange is strictly ordered:
|
||||
|
||||
* DH of the Long term identity of the outbound connection by the ephemeral
|
||||
key of the inbound connection.
|
||||
|
|
|
|||
48
src/cwtch.md
48
src/cwtch.md
|
|
@ -1,51 +1,30 @@
|
|||
# Cwtch Library
|
||||
|
||||
# Known Risks
|
||||
|
||||
|
||||
## Thread Safety
|
||||
|
||||
**Status: Partially Mitigated (Work in Progress)**
|
||||
|
||||
The Cwtch library evolved from a prototype that had weak checks around
|
||||
concurrency and the addition of singleton behavior around saving profiles to
|
||||
files and protocol engines resulted in race conditions.
|
||||
|
||||
The inclusion of the `Event Bus` made handling such cases easier, and the
|
||||
majority of the code is now tested via unit tests and integration test
|
||||
running the `-race` flag. The last portion of the code that requires work in
|
||||
this regard are around the AppBridge and Server which are used by the UI to
|
||||
maintain separation.
|
||||
|
||||
## Private information transiting the IPC boundary
|
||||
|
||||
**Status: Unmitigated (Requires privileged user to exploit)**
|
||||
**Status: Requires privileged user to exploit**
|
||||
|
||||
Information used to derive the encryption key used to save all sensitive data to
|
||||
the file system cross the boundary between the UI front-end and the App backend.
|
||||
|
||||
Intercepting this information requires a privileged position on the local
|
||||
machine. There are currently no plans to mitigate this issue.
|
||||
machine.
|
||||
|
||||
|
||||
|
||||
|
||||
## Testing Status
|
||||
|
||||
Cwtch features one well-defined integration test which exercise the ideal case of
|
||||
Cwtch features one [well-defined integration test](https://openprivacy.ca/discreet-log/06-cwtch-integ-tests/) which exercise the ideal case of
|
||||
three well-formed peers authenticating and messaging each other through an
|
||||
untrusted server.
|
||||
|
||||
In addition, unit tests are defined for a number of Cwtch modules, however
|
||||
many of them have become outdated with the introduction of Tapir.
|
||||
|
||||
Most tests are run with the `-race` flag which will cause them to fail if
|
||||
Tests are run with the `-race` flag which will cause them to fail if
|
||||
race conditions are detected.
|
||||
|
||||
Both integration tests and unit tests are run automatically for every pull request and main branch merge.
|
||||
|
||||
## Resolved or Outdated Risks
|
||||
|
||||
|
||||
|
||||
### Dependency on Outdated Protobuf Implementation
|
||||
|
||||
**Status: Mitigated**
|
||||
|
|
@ -75,4 +54,17 @@ against the server adjusting difficulty too often would also mitigate some of
|
|||
the more extreme vectors.
|
||||
|
||||
Additionally, Token Based Services and Peer-based Groups are both potential
|
||||
options for eliminating this attack vector entirely.
|
||||
options for eliminating this attack vector entirely.
|
||||
|
||||
## Thread Safety
|
||||
|
||||
**Status: Mitigated **
|
||||
|
||||
The Cwtch library evolved from a prototype that had weak checks around
|
||||
concurrency, and the addition of singleton behavior around saving profiles to
|
||||
files and protocol engines resulted in race conditions.
|
||||
|
||||
The inclusion of the `Event Bus` made handling such cases easier, and the
|
||||
code is now tested via unit tests and integration test
|
||||
running the `-race` flag.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,17 +3,15 @@
|
|||
|
||||
## Risk: Binaries are replaced on the website with malicious ones
|
||||
|
||||
**Status: Unmitigated**
|
||||
**Status: Partially-mitigated**
|
||||
|
||||
While this process is now mostly automated, should this automation ever be
|
||||
compromised then there is nothing in our current process that would detect this.
|
||||
|
||||
We need:
|
||||
|
||||
* Reproducible Builds - it is unlikely that we will be able to do this
|
||||
overnight, several parts of our build process (Qt builds, the recipe etc.)
|
||||
may introduce non-determinism. Nevertheless, we should seek to identify where
|
||||
this non-determinism is.
|
||||
* Reproducible Builds - we currently use puplic docker containers for all builds
|
||||
which should allow anyone to compare distributed builds with ones built from source.
|
||||
* Signed Releases - Open Privacy does not yet maintain a public record of staff
|
||||
public keys. This is likely a necessity for signing released builds and
|
||||
creating an audit chain backed by the organization. This process must be
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 104 KiB |
|
|
@ -0,0 +1,57 @@
|
|||
# Message Overlays
|
||||
|
||||
[Adapted from: Discreet Log #8: Notes on the Cwtch Chat API](https://openprivacy.ca/discreet-log/08-chatapi/)
|
||||
|
||||
We envision Cwtch as a platform for providing an authenticated transport layer to higher-level applications.
|
||||
Developers are free to make their own choices about what application layer protocols to use,
|
||||
whether they want bespoke binary message formats or just want to throw an HTTP library on top and call it a
|
||||
day. Cwtch can generate new keypairs for you (which become onion addresses; no need for any DNS registrations!)
|
||||
and you can REST assured that any data your application receives from the (anonymous communication)
|
||||
network has been authenticated already.
|
||||
|
||||
For our current stack, messages are wrapped in a minimal JSON frame that adds
|
||||
some contextual information about the message type.
|
||||
And because serialised JSON objects are just dictionaries, we can easily add more metadata later on as needed.
|
||||
|
||||
|
||||
## Chat overlays, lists, and bulletins
|
||||
|
||||
The original Cwtch alpha demoed "overlays": different ways of interpreting the same data channel,
|
||||
depending on the structure of the atomic data itself. W
|
||||
|
||||
e included simple checklists and BBS/classified ads as overlays that could be viewed
|
||||
and shared with any Cwtch contact, be it a single peer or a group. The wire format looked like this:
|
||||
|
||||
```
|
||||
{o:1,d:"hey there!"}
|
||||
{o:2,d:"bread",l:"groceries"}
|
||||
{o:3,d:"garage sale",p:"[parent message signature]"}
|
||||
```
|
||||
|
||||
Overlay field `o` determined if it was a chat (1), list (2), or bulletin (3) message.
|
||||
The data field `d` is overloaded, and lists/bulletins need additional information about what
|
||||
group/post they belong to. (We use message signatures in place of IDs to avoid things like message
|
||||
ordering problems and maliciously crafted IDs. This is also how the Cwtch protocol communicates to the
|
||||
front end which message is being acked.)
|
||||
|
||||
## Data structure
|
||||
|
||||
Implementing tree-structured data on top of a sequential message store comes with obvious
|
||||
performance disadvantages. For example, consider the message view, which loads most-recent-messages first and only goes back far enough to fetch enough messages to fill the current viewport, in comparison with a (somewhat pathological) forum where almost every message is a child of the very first message in the history, which could have been gigs and gigs of data-ago. If the UI only displays top-level posts until the user expands them, we have to parse the entire history before we get enough info to display anything at all.
|
||||
|
||||
Another problem is that multiplexing all these overlays into one data store creates "holes" in the data that confuse [lazy-loaded listviews](https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html) and scrollbars. The message count may indicate there is a ton more information to display if the user simply scrolls, but when it actually gets fetched and parsed we might realize that none of it is relevant to the current overlay.
|
||||
|
||||
None of these problems are insurmountable, but they demonstrate a flaw in our initial assumptions about the nature of collaborative message flows and how we should be handling that data.
|
||||
|
||||
## Invitations
|
||||
|
||||
Instead of receiving the invite as an incoming contact request at the profile level, new inline invites are shared with a particular contact/group, where they can be viewed and/or accepted later, even if they were initially rejected (potentially by accident).
|
||||
|
||||
The wire format for these are equally simple:
|
||||
|
||||
```
|
||||
{o:100,d:"u4ypg7yyyrrvf2aceeclq5dgwtkirzletltbqofnb6km7u542qqk4jyd"}
|
||||
{o:101,d:"torv3eyJHcm91cElEIjoiOWY3MWExYmFhNDkzNTAzMzAyZDFmODRhMzI2ODY2OWUiLCJHcm91cE5hbWUiOiI5ZjcxYTFiYWE0OTM1MDMzMDJkMWY4NGEzMjY4NjY5ZSIsIlNpZ25lZEdyb3VwSUQiOiJyVGY0dlJKRkQ2LzFDZjFwb2JQR0xHYzdMNXBKTGJTelBLRnRvc3lvWkx6R2ZUd2Jld0phWllLUWR5SGNqcnlmdXVRcjk3ckJ2RE9od0NpYndKbCtCZz09IiwiVGltZXN0YW1wIjowLCJTaGFyZWRLZXkiOiJmZVVVQS9OaEM3bHNzSE9lSm5zdDVjNFRBYThvMVJVOStPall2UzI1WUpJPSIsIlNlcnZlckhvc3QiOiJ1cjMzZWRid3ZiZXZjbHM1dWU2anBrb3ViZHB0Z2tnbDViZWR6ZnlhdTJpYmY1Mjc2bHlwNHVpZCJ9"}
|
||||
```
|
||||
|
||||
This represents a departure from our original "overlays" thinking to a more action-oriented representation. The chat "overlay" can communicate that someone *did* something, even if it's paraphrased down to "added an item to a list," and the lists and bulletins and other beautifully chaotic data can have their state precomputed and stored separately.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Overview
|
||||
|
||||
Welcome to the Cwtch Secure Development Handbook. The purpose of this
|
||||
Welcome to the Cwtch Secure Development Handbook! The purpose of this
|
||||
handbook is to provide a guide to the various components of the Cwtch
|
||||
ecosystem, to document the known risks and mitigations, and to enable
|
||||
discussion about improvements and updates to Cwtch secure development
|
||||
|
|
@ -9,7 +9,7 @@ processes.
|
|||
|
||||
|
||||
|
||||
## History
|
||||
## A (Brief) History of Metadata Resistant Chat
|
||||
|
||||
In recent years, public awareness of the need and benefits of end-to-end
|
||||
encrypted solutions has increased with applications like [Signal](https://signalapp.org),
|
||||
|
|
@ -20,20 +20,42 @@ However, these tools require various levels of metadata exposure to function,
|
|||
and much of this metadata can be used to gain details about how and why a person
|
||||
is using a tool to communicate. [[rottermanner2015privacy]](https://www.researchgate.net/profile/Peter_Kieseberg/publication/299984940_Privacy_and_data_protection_in_smartphone_messengers/links/5a1a9c29a6fdcc50adeb1335/Privacy-and-data-protection-in-smartphone-messengers.pdf).
|
||||
|
||||
One tool that does seek to reduce metadata is [Ricochet](https://ricochet.im) first released in 2014.
|
||||
Ricochet uses Tor onion services to provide secure end-to-end encrypted communication,
|
||||
One tool that did seek to reduce metadata is [Ricochet](https://ricochet.im) first released in 2014.
|
||||
Ricochet used Tor v2 onion services to provide secure end-to-end encrypted communication,
|
||||
and to protect the metadata of communications.
|
||||
|
||||
There are no centralized servers that assist in routing Ricochet
|
||||
conversations. No one other than the parties involved in a conversation can
|
||||
There were no centralized servers that assist in routing Ricochet
|
||||
conversations. No one other than the parties involved in a conversation could
|
||||
know that such a conversation is taking place.
|
||||
|
||||
Ricochet isn't without limitations; there is no multi-device support, nor is
|
||||
there a mechanism for supporting group communication or for a user to send
|
||||
messages while a contact is offline.
|
||||
Ricochet wasn't without limitations; there was no multi-device support, nor is
|
||||
there a mechanism for supporting group communication or for a user to send
|
||||
messages while a contact is offline.
|
||||
|
||||
This makes adoption of Ricochet a difficult proposition; with even those in
|
||||
environments that would be served best by metadata resistance unaware that it
|
||||
This made adoption of Ricochet a difficult proposition; with even those in
|
||||
environments that would be served best by metadata resistance unaware that it
|
||||
exists [[ermoshina2017can]](www.academia.edu/download/53192589/ermoshina-12.pdf)
|
||||
[[renaud2014doesn]](https://eprints.gla.ac.uk/116203/1/116203.pdf).
|
||||
|
||||
Additionally, any solution to decentralized, metadata resistant communication faces [fundamental problems](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems)
|
||||
when it comes to efficiency, privacy and group security (as defined by [transcript consensus and consistency](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems)).
|
||||
|
||||
Modern alternatives to Ricochet include [Briar](https://briarproject.org), [Zbay](https://www.zbay.app/)
|
||||
and [Ricochet Refresh](https://www.ricochetrefresh.net/) - each tool seeks to optimize for a different
|
||||
set of trade-offs e.g. Briar seeks to allow people to communicate [even when underlying network infrastructure
|
||||
is down](https://briarproject.org/how-it-works/) while providing resistant to metadata surveillance.
|
||||
|
||||
<hr/>
|
||||
|
||||
The Cwtch project began in 2017 as an extension protocol for Ricochet providing group conversations via
|
||||
untrusted servers, with an eye to enabling decentralized, metadata resistant applications (like shared lists
|
||||
and bulletin board)
|
||||
|
||||
An alpha version of Cwtch was [was launched in February 2019](https://openprivacy.ca/blog/2019/02/14/cwtch-alpha/), and
|
||||
since then the Cwtch team (run by the [Open Privacy Research Society](https://openprivacy.ca)) has conducted
|
||||
research and development into cwtch and the underlying protocols and libraries and problem spaces.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,27 @@
|
|||
# References
|
||||
|
||||
* Nik Unger et al. “SoK: secure messaging”. In:Security and Privacy (SP
|
||||
), 2015 IEEE Sympo-sium on. IEEE. 2015, pp. 232–249 [link](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf)
|
||||
|
||||
* Atwater, Erinn, and Sarah Jamie Lewis. "Token Based Services-Differences from Privacy Pass."
|
||||
|
||||
* Brooks, John. Ricochet: Anonymous instant messaging for real privacy. https://ricochet.im. Accessed: 2018-03-10
|
||||
|
||||
* Ermoshina K, Halpin H, Musiani F. Can johnny build a protocol? co-ordinating developer and user intentions for privacy-enhanced secure messaging protocols. In European Workshop on Usable Security 2017.
|
||||
|
||||
* Ermoshina, K., Musiani, F. and Halpin, H., 2016, September. End-to-end encrypted messaging protocols: An overview. In International Conference on Internet Science (pp. 244-254). Springer, Cham.
|
||||
|
||||
* Farb, M., Lin, Y.H., Kim, T.H.J., McCune, J. and Perrig, A., 2013, September. Safeslinger: easy-to-use and secure public-key exchange. In Proceedings of the 19th annual international conference on Mobile computing & networking (pp. 417-428).
|
||||
|
||||
* Greschbach, B., Kreitz, G. and Buchegger, S., 2012, March. The devil is in the metadata—New privacy challenges in Decentralised Online Social Networks. In 2012 IEEE international conference on pervasive computing and communications workshops (pp. 333-339). IEEE.
|
||||
|
||||
* Langley, Adam. Pond. https://github.com/agl/pond. Accessed: 2018-05-21.
|
||||
|
||||
* Le Blond, S., Zhang, C., Legout, A., Ross, K. and Dabbous, W., 2011, November. I know where you are and what you are sharing: exploiting p2p communications to invade users' privacy. In Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (pp. 45-60).
|
||||
|
||||
* Lewis, Sarah Jamie. "Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party and Metadata Resistant Applications." (2018).
|
||||
|
||||
* Renaud, K., Volkamer, M. and Renkema-Padmos, A., 2014, July. Why doesn’t Jane protect her privacy?. In International Symposium on Privacy Enhancing Technologies Symposium (pp. 244-262). Springer, Cham.
|
||||
|
||||
* Rottermanner, C., Kieseberg, P., Huber, M., Schmiedecker, M. and Schrittwieser, S., 2015, December. Privacy and data protection in smartphone messengers. In Proceedings of the 17th International Conference on Information Integration and Web-based Applications & Services (pp. 1-10).
|
||||
|
||||
* Unger, Nik et al. “SoK: secure messaging”. In: Security and Privacy (SP
|
||||
), 2015 IEEE Sympo-sium on. IEEE. 2015, pp. 232–249 [link](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf)
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ expected to provide:
|
|||
We note here that these properties are a superset of the design aims of Private
|
||||
Information Retrieval structures.
|
||||
|
||||
## Malcious Servers
|
||||
## Malicious Servers
|
||||
|
||||
We expect the presence of malicious entities within the Cwtch ecosystem.
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ guarantee more efficient properties by relaxing trust and security
|
|||
members then there will be a detectable gap in the message tree of certain
|
||||
peers that can be discovered through peer-to-peer gossip.
|
||||
* A Cwtch server cannot modify any message without the key material known to
|
||||
the group (any attempt to do so for a subset of group memebers will result in
|
||||
the group (any attempt to do so for a subset of group members will result in
|
||||
identical behavior to failing to relay a message).
|
||||
* While a server *can* duplicate messages, these will have no impact on the
|
||||
group message tree (because of encryption, nonces and message identities) -
|
||||
|
|
@ -58,10 +58,26 @@ This has an obvious impact on bandwidth efficiency, especially for peers using
|
|||
mobile devices, as such we are actively developing new protocols in which the
|
||||
privacy and efficiency guarantees can be traded-off in different ways.
|
||||
|
||||
The most developed idea is to bucket the messages on the server into discrete
|
||||
time windows and allow peers to fetch smaller batches, coupled with the
|
||||
underlying tor connection this technique should provide sufficient privacy -
|
||||
although the technique still needs formal verification.
|
||||
As of writing, the servers allow both a complete download of all stored messages, and a
|
||||
request to download messages from a certain specified message.
|
||||
|
||||
All peers when they first join a group on a new server download all messages from the server, and
|
||||
from then on download only new messages.
|
||||
|
||||
*Note*: This behaviour does permit a mild form of metadata analysis. The server can new messages for each
|
||||
suspected unique profile, and then use these unique message signatures to track unique sessions over time (
|
||||
via requests for new messages).
|
||||
|
||||
This is mitigated by 2 confounding factors:
|
||||
|
||||
1. Profiles can refresh their connections at any time - resulting in fresh server session.
|
||||
2. Profiles can "resync" from a server at any time - resulting in a new call to download all messages. The most
|
||||
common usecase for this behaviour is to fetch older messages from a group.
|
||||
|
||||
In combination, these 2 mitigations place bounds on what the server is able to infer however we still cannot
|
||||
provide full metadata-resistance.
|
||||
|
||||
For potential future solutions to this problem see [Niwl](https://git.openprivacy.ca/openprivacy/niwl)
|
||||
|
||||
# Protecting the Server from Malicious Peers
|
||||
|
||||
|
|
|
|||
65
src/ui.md
65
src/ui.md
|
|
@ -1,49 +1,68 @@
|
|||
# Cwtch UI
|
||||
|
||||
The UI is built on [therecipe/qt](https://github.com/therecipe/qt) which
|
||||
links in Qt libraries.
|
||||
|
||||
|
||||
The UI is now built using [flutter](https://flutter.dev/).
|
||||
|
||||
# Known Risks
|
||||
|
||||
|
||||
## Deanonymization through Content Injection
|
||||
|
||||
**Status: Mitigated in several places**
|
||||
**Status: Mitigated in several places**
|
||||
|
||||
Like most UI frameworks, QML provides a HTML rendering engine with the potential
|
||||
to make requests through remote resource loading. Any kind of malicious content
|
||||
injection is therefore elevated to a critical deanonymization risk.
|
||||
Unlike most UI frameworks, Flutter is not a de-facto HTML rendering engine. Any kind of malicious content
|
||||
injection is therefore not-elevated to a critical deanonymization risk in the default case.
|
||||
|
||||
To mitigate such a risk we do the following:
|
||||
To further mitigate this risk:
|
||||
|
||||
* Maintain our own UI library that explicitly relies on PlainText fields to
|
||||
handle all content (and thus styled safely)
|
||||
* Maintain our own set of core UI widgets that the rest of the app relies on that do not
|
||||
make use of any component widgets that may hit the network e.g. [Image.network](https://api.flutter.dev/flutter/widgets/Image/Image.network.html)
|
||||
* Mediate all Cwtch api networking calls through Tor
|
||||
* Force QML to use a deliberately broken network resolver that is incapable of
|
||||
resolving remote content
|
||||
* Frequently test the UI for potential content injection vulnerabilities.
|
||||
* Frequently test the UI for potential content injection vulnerabilities via FuzzBot
|
||||
|
||||
While none of these mitigations should be assumed robust by themselves, the
|
||||
combination of them should be sufficient to prevent such attacks.
|
||||
|
||||
|
||||
## Corruption of UI Chrome through Content Injection
|
||||
|
||||
**Status: Mitigated**
|
||||
|
||||
While we assess the mitigated-risk of content injection resulting in deanonymization vectors to be very low,
|
||||
the risk that malicious content causes UI chrome corruption requires additional consideration.
|
||||
|
||||
As a simple example, unicode control characters from conversations should not result in corruption to parts of the
|
||||
chrome that they are rendered with.
|
||||
|
||||
|
||||
|
||||
To mitigate this risk:
|
||||
|
||||
* All potentially malicious content is rendered separately at the widget level i.e. we do not mix trusted
|
||||
strings and untrusted strings in the same widget. This confined rendering differences tightly to just the
|
||||
malicious content.
|
||||
* Frequently test the UI for potential content injection vulnerabilities via FuzzBot
|
||||
|
||||
## Denial of Service through Spamming
|
||||
|
||||
**Status: Partially Mitigated**
|
||||
**Status: Partially Mitigated**
|
||||
|
||||
There is currently no limitation on the number of messages that can be sent
|
||||
to a Cwtch server or by a Cwtch peer. Each message requires process and is
|
||||
added to the UI if valid.
|
||||
added to the UI if valid.
|
||||
|
||||
We have put in work to ensure that an influx of messages does not degrade the
|
||||
app experience, however it will result in an increase in network badwidth which
|
||||
app experience, however it will result in an increase in network bandwidth which
|
||||
may be intolerable or undesired for many people - especially those on metered
|
||||
connections (e.g. cellphone data plans)
|
||||
|
||||
In order to be suitable to deploy groups at a wide scale, the app require a way
|
||||
connections (e.g. cellphone data plans)
|
||||
|
||||
In order to be suitable to deploy groups at a wide scale, the app requires a way
|
||||
to prevent Cwtch from fetching information over such connections, and this
|
||||
should likely be turned on by default.
|
||||
|
||||
## Testing Status
|
||||
|
||||
The UI is currently only subject to manual testing.
|
||||
## Testing Status
|
||||
|
||||
The UI is subject to both manual testing, partially automated testing through fuzzbot, and fully
|
||||
automated testing during pull requests.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue