Skip to content

bugfix: Ensure Vertex Source Selectors are recursive. feat: Add getters for recursive. #380

Merged
Entenwilli merged 6 commits into
DataFlowAnalysis:mainfrom
niki21r:main
Feb 25, 2026
Merged

bugfix: Ensure Vertex Source Selectors are recursive. feat: Add getters for recursive. #380
Entenwilli merged 6 commits into
DataFlowAnalysis:mainfrom
niki21r:main

Conversation

@niki21r

@niki21r niki21r commented Feb 24, 2026

Copy link
Copy Markdown
Contributor

This Pull request covers two things:

  1. First it fixes a bug where some Vertex Selectors were not recursive, even if they were used as a Source Selector. According to my understanding all Vertex Selectors that are Source Selectors should be recursive.

  2. Secondly it introduces getters for the recursive boolean to Vertex Selectors that could be recursive. These getters could be used for tests. I now also need them for proper encoding of confidentiality constraints for my thesis. Previously I decided on recursive or non-recursive semantics for a selector depending on whether it was a Source or Destination Selector. However since bugs like the one I suspect here could happen because of this I want direct access to the selectors instead.

@niki21r

niki21r commented Feb 24, 2026

Copy link
Copy Markdown
Contributor Author

Hier ein konkretes Beispiel für den WebEditor wo das Fehlen des rekursiven Verhaltens mMn keine Violation anzeigt, obwohl der zweite Knoten eigentlich eine haben sollte:
diagram.json
mit dem Constraint: - Test: vertex Sensitivity.Personal,Location.EU neverFlows vertex Location.nonEU

@uuqjz uuqjz requested a review from Entenwilli February 24, 2026 20:27
@Entenwilli

Copy link
Copy Markdown
Member

In general, most selectors should not act recursively.
Vertex Characteristic Selectors are almost always used to check whether a specific node (and not any one of its previous vertices) matches the selector.

Therefore, if you desire the behavior, you should create the selectors manually and add them to the constraint you are building.

@niki21r

niki21r commented Feb 25, 2026

Copy link
Copy Markdown
Contributor Author

So it is intended that these two constraints have the same semantics?

new ConstraintDSL().fromNode().withCharacteristic("DummyType", List.of("A", "B")).neverFlows().toVertex().create();
new ConstraintDSL().fromNode().neverFlows().toVertex().withCharacteristic("DummyType", List.of("A", "B")).create();

If so, can I alter the pull request to include the getters at least?

@Entenwilli

Copy link
Copy Markdown
Member

So it is intended that these two constraints have the same semantics?

new ConstraintDSL().fromNode().withCharacteristic("DummyType", List.of("A", "B")).neverFlows().toVertex().create();
new ConstraintDSL().fromNode().neverFlows().toVertex().withCharacteristic("DummyType", List.of("A", "B")).create();

If so, can I alter the pull request to include the getters at least?

Yes, the Semantics are the same.

The getters should have been there in the first place, so that is fine

@niki21r

niki21r commented Feb 25, 2026

Copy link
Copy Markdown
Contributor Author

Are you really sure though?
I think it is quite unintuitive that VertexCharacteristicsListSelectors should be the only ones that are never recursive, irrespective of the fact that they are Source or Destination Selectors.

Because normal VertexCharacteristicsSelectors and VertexTypeSelectors are recursive when used as Source Selectors, while they are not when used as Destination Selectors .

I think it would be intuitive that the recursion behavior is the same, irrespective of the concrete Entities they match on. If all Source Selectors are never meant to be recursive, the question of why recursion does even exist arises. Therefore I think these flags where just forgotten when writing the two methods I included in my pull request. If you are really sure I can stash those changes though.

@uuqjz

uuqjz commented Feb 25, 2026

Copy link
Copy Markdown
Collaborator

@niki21r Entenwilli created the DSL. If he says it is not intended you can take his word.
You can keep the getter but stash the other changes

@niki21r

niki21r commented Feb 25, 2026

Copy link
Copy Markdown
Contributor Author

Alright, I reverted the respective commit so this pull request now only contains the Getters

@Entenwilli Entenwilli merged commit 5eaa027 into DataFlowAnalysis:main Feb 25, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants