Bug 1542060
| Summary: | add UUID signatures, like openSUSE has for Zypper | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Miller <mattdm> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | CC: | carl, dmach, jberan, packaging-team-maint, rpm-software-management, samuel-rhbugs, smooge, thib, vmukhame, walters |
| Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-03-02 15:40:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Matthew Miller
2018-02-05 13:25:06 UTC
So in order to cut down the amount of data that might be tracked, maybe look at making things not so unique. The goal is to try and get an idea about how many ips are behind a NAT per day. If we take the system uuid and mod it by 2^13-1 (or some other small mersenne prime) that would give a rotation of 8191 so while there will be 'duplicates', we are likely to see the same number at different ips per day. The system uuid can be controlled by the user and/or regenerate daily or whatever is needed. I expect that this has flaws but hopefully ones which aren't completely demasking. Specifically, what I want is: * The randomized UUID * The CPU architecture * ID, VERSION_ID, and VARIANT_ID from /etc/os-release I think using a completely random UUID is better than a modification of system ID or other persistent data. Note also that we need this at a level that works in the DNF command line, microdnf, and PackageKit. This seems like it's thinking about dnf on host systems - what about in containers? (In reply to Colin Walters from comment #3) > This seems like it's thinking about dnf on host systems - what about in > containers? I'm thinking about both. Right now, we only set VARIANT_ID for a few flavors (the Fedora Editions, and Cloud Base for historical reasons). I'd like to change that to be different in our container image, too — maybe just "container". Is there something more I should be thinking about? This approach, of course, wouldn't link the containers to their host in any way and would count each one uniquely; I can't think of a privacy-preserving way to do that offhand. > and would count each one uniquely;
Right, what I'm getting at is that this is going to pick up a lot of `docker build` type scenarios, and *not* pick up each time that image is deployed in an e.g. Kube cluster.
That's of course true for "classic host images" like using Packer or whatever to make AMIs, and for custom rpm-ostree imaging. We could perhaps teach rpm-ostree to use different user agents for client vs build/compose side.
Of course on the infrastructure server side we could just have a clear separation between containers versus hosts, but the fact that we don't differentiate the container base image today is exactly what I'm getting at here.
Also, AFAIK today nothing in the dnf/libdnf stack really tries to determine "am I in a container" in a reliable way. That's always been an interesting topic... Changing the base image OS variant makes sense to me offhand, I'm not sure why we didn't do that a long time ago.
We have discussed that we're not going to send UUID as it might allow user tracking. There's user-agent and 'countme' work in progress in bug#1156007 and PR https://github.com/rpm-software-management/libdnf/pull/684 *** This bug has been marked as a duplicate of bug 1156007 *** |