Issue 242: add an @interfaces expandable endpoint

[erral]

See #242

[coveralls]

Coverage increased (+0.02%) to 96.583% when pulling 8b7f54c7c419149a44e1c62b9095257fdb24ae33 on issue-242-erral-interfaces into 88a6779c21b71cc359b4b80b640a0bfb6c0eb188 on master.

[coveralls]

Coverage increased (+0.02%) to 96.583% when pulling 8b7f54c7c419149a44e1c62b9095257fdb24ae33 on issue-242-erral-interfaces into 88a6779c21b71cc359b4b80b640a0bfb6c0eb188 on master.

[coveralls]

Coverage increased (+0.02%) to 96.583% when pulling 8b7f54c7c419149a44e1c62b9095257fdb24ae33 on issue-242-erral-interfaces into 88a6779c21b71cc359b4b80b640a0bfb6c0eb188 on master.

[buchi]

👍 LGTM

I wonder if exposing all those interface names publicly may lead to unwanted information disclosure.

[erral]

Yeah... during the training we wondered if we could restrict somehow the list of exposed interfaces, or at least set a list of known-good-set of interfaces, and expose just them...

[tisto]

@erral LGTM as well. Though, as @buchi said, the interfaces are currently not visible by anonymous users. Therefore we might have to think about this...

[erral]

I share your concerns about the public visibility of the interfaces. Nevertheless they are needed, at least to know the navigation contexts when the front-end wants to build the global navigation for instance.

@ebrehault any comment on this?

[coveralls]

Coverage increased (+0.02%) to 96.657% when pulling 5671b3334ab6b333048a7c89f53778c38f3db2df on issue-242-erral-interfaces into 8a84333444d565d4e2b8bec379353d5db4d2c18e on master.

[coveralls]

Coverage increased (+0.3%) to 96.389% when pulling d8552846d0a05a1ecbd770f163a86c3db59ed919 on issue-242-erral-interfaces into 41b9bf67295fffdce1eff82390419ce27b51344f on master.

[tkimnguyen]

What would you recommend as a way of restricting who has access to this?

[jensens]

So, what is the problem with exposing?

Does exposing information about interfaces - and so about installed add-ons and other internals - give attackers hints about possible vulnerabilities outside of the core? But also FTI info and other endpoints expose that information.

I doubt it a problem, but I would love to hear opposing opinions.

[mauritsvanrees]

In PloneHotfix20161129 we removed the docstrings of lots of zope.interface methods and attributes to avoid 'publishing' them, that is making them available for browsers to call. See https://github.com/zopefoundation/Zope/pull/81. In some cases they could really be used for potential harm (setting values), in others it was: better safe than sorry.

Just giving the name of interfaces should be fine. But it does give you info about an object that is useful for a UI but also for potential hackers. So a way to whitelist some interfaces, or to completely disable this (return an empty list) for the security conscious would be good.

[jensens]

What is the state here? Do we want it or not? If not and hence there was no activity for a long time, I propose to close this PR within next two weeks. If you do not feel OK with this, please speak up and provide us a rough schedule.

[tisto]

@jensens it is something we definitely want. Though, there are lots of things to consider and to discuss. I'd prefer to keep it open. Maybe something that can be discussed at one of the next sprints this year...

[jensens]

This one got forgotten. Is it still valid or meanwhile superseded?

[erral]

I am closing this because the main reason for this, the navigation root thing, has been fixed using another endpoint. If we need to expose the interfaces in the future we can use this code as an inspiration, but we do not need this right now.