: patch set to update the git reference policy
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 19 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 19 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [refpolicy] [PATCH/RFC 0/19]: patch set to update the git reference policy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 23 lines · Guido Trentalancia
Hello Dominick,
thanks for your reply !
Quoted 4 lines · Dominick Grift
Quoted 3 lines · Guido Trentalancia
Quoted 2 lines
I did a quick review of your policy and commented inline. I think most of it is probably not acceptable at this point unfortunately.
Quoted 8 lines
Quoted 5 lines
Yes, I have started to look at your comments. Of course they are all good points that you have made and that need to be changed.
But after those issues will have been fixed, what else would prevent the patch from being committed ?
For example the way you deal with dbus chat, is not the way refpolicy usually deas with it.
Yes, I know.
Quoted 3 lines
Where you have dbus_*_send interfaces that only go one way, refpolicy uses dbus_*_chat interfaces that are bi-directional.
Quoted 8 lines
Quoted 4 lines
This is because if some process send a message and is allowed that, then one can be sure that the receiving party will want to reply to that message and that you will want to allow that reply (why else would you have allowed the initial party to send a message in the first place?
This is one thing I definitely not agree with. The way it's implemented in the patch is better in my opinion. It is more flexible and it is more in line with the aims of a reference policy.
Well, i am not sure about it. Security is a trade off between security and usability. Ask your self does this added complexity of yours really add valuable security? Are there any cases where one party sends a message without getting a reply?
Quoted 10 lines
One should not assume anything. Permissions to
send_msgshould be given to each module separately only for what concerns that module (and not the other party which might eventually be involved in a "chat"). A chat is a concept too advanced for a reference policy. The policy should just grant permissions for a module to send out something. It should not even know that a "chat" is having place.Of course, this is my point of view. If it necessarily needs to be the other way to get committed, it can still be changed but I would certainly do things differently on my side.
i am just an humble hobbyist with an opinion. I to would be interested to hear others (especially people with authority) opinion on it. But from experience i can tell you that it is almost if not always a chat thing.
Quoted 12 lines
There are many changes that you propose. Apart from this latest one (which is somewhat also mentioned in [2/19]), I am in perfect agreement with what you say (well, to be honest I still need to look more carefully at the feasibility of [5/19], [6/19], [8/19] and [13/19] but there shouldn't be any problem as long as it is feasible). Because there are many changes to carry out, I would prepare new patches only if it is then worth committing them... Nobody else has commented anything. I still think it's really worth applying these changes to the reference policy (or otherwise it seems that basic functionality of a generic system is not being guaranteed) !
My advice is that you send small patches for each functionality and explain why its needed in as much detail as possible. ofcourse you should make sure you apply style rules and also make sure you compare your changes with similar policy in refpolicy to see if your change complies with refpolicy design. (e.g. the decisions refpolicy made with regard to how particular issue should be handled)
I have proposed many patches to refpolicy. Several had many revision and eventually were not accepted. It is in my view not easy to maintain an upstream policy because there are many things to take into account before you can accept a patch. That also means that the submitter has to know alot of properties of refpolicy.
Else the maintainer spends all his time reviewing patches and explaining people about these properties over and over again.
So before you submit, double... triple check your patches.
The first time one submit a patch that has mistakes is not a big deal, the second time i guess neither. But one sends many patches that keep having issues and the maintainer has to review them all, then i can imagine that after a while the maintainer is not so eager anymore to review it...
So the point of all this is. Best to spend a little more time getting familair with the properties of the policy, and be confident that any patch you submit has a high chance of getting accepted. So verify style, properties etc.
This also to save yourself some frustration.
Again, though, i am just an hobbyist. I have no authority and i am just trying to help.
Quoted 6 lines
I would really need to know before I proceed...
Regards,
Guido
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk097bAACgkQMlxVo39jgT+LZgCePiXR6U4rWrMR3EDuQKwDLuyz lEkAniIuzEAbNKP505VgfIEwQ5NoJTWH
=bsId
-----END PGP SIGNATURE-----