Weekly meeting summary | 4th June 2020

8 views
Skip to first unread message

Aditya Singh

unread,
Jun 6, 2020, 1:59:15 PM6/6/20
to checker-framework-gsoc
Date : 4th June 2020

In my 3rd meeting with my mentor (Dr. Werner Dietl), I shared my progress during the week with him, along with some doubts that came up while working. These include inquiring about requested changes on my pull requests, files that require changes, alternative ways to solve issues, etc.

As per review of my pull request (3313-leak-in-constructor-error-fix), I was advised to use JDK annotation to make the Object class unique, instead of a stubfile in the Aliasing Checker directory. I discussed the issue with Dr. Dietl and he advised me to work on it in the coming week. My 2nd pull request is also currently undergoing a review, and I will promptly incorporate any suggested changes.

We also reviewed the proposed ideas list and figured out which parts to work on and which ones to modify. Dr. Dietl suggested that I divide my task with the Tainting Checker into 3 levels; each level adding some new set of features or an increased degree of user customization.
  • Level 1 : Add a string argument to the tainting checker, similar to the Fake Enumeration checker. The string arguments will define the type for which the object can be tainted or untainted. Additionally, the Tainting                      Checker should work without any arguments as well (like it currently does).

  • Level 2 : The 2nd level will enable the user to create his/her own checkers in the form of a comment line and also declare its hierarchy. This would make sure that @Untainted objects don't have universal access and,                       hence, can be handled with more scrutiny.

  • Level 3 : The 3rd level will enable the user to create and customize his/her own type rules for the Tainting Checker as well as declare its subtypes. Hence, the user can create his/her own tainting checker annotations                (like @SQLquery, @OScommand, etc), each with their own unique hierarchies, type rules and subtype checkers.
Dr. Dietl also pointed out an issue I can look into (Implement Dump-on-Error alternative #1395). It deals with making the CheckerMessage store the stacktrace of where it was originally created and adding/modifying/reusing a dump on error flag to output this information. This can greatly help in debugging the checker framework since the user can pin point where the error has occurred.

I have started my work to complete all of these objectives and I will update everyone about my progress on these fronts, in my next week's report.

Regards,
Aditya Singh

Werner Dietl

unread,
Jun 7, 2020, 1:10:55 PM6/7/20
to Aditya Singh, checker-framework-gsoc
Hi Aditya,

thanks for the update!

Let me clarify Levels 2 and 3 a bit:
- Level 2 was to provide a Tainting Checker variant that can be
customized by the tainting annotations, similarly to how the Subtyping
Checker can be customized with annotations. This already allows the
user to define custom annotations (like @SqlTrusted and @SqlUntrusted)
and additionally allows to have a finer-grained hierarchy (e.g.
@Public, @Confidential, and @TopSecret).

- Level 3 is to introduce a custom checker, built on top of the
qualifiers defined before. This progression is similar to how
initially one can just define the type hierarchy and use the Subtyping
Checker. Once that is not enough, a developer can write their own
Checker subclass to also customize rules. Similarly, this should make
it easy to provide a custom Tainting Checker subclass.

I'm not sure what you mean with "in the form of a comment line" in the
Level 2 description. Can you clarify?
I was thinking that the normal @SubtypeOf meta-annotations should be
enough to declare the hierarchy of custom tainting annotations.

Do make sure you read through the "Create your own Checker" section
https://checkerframework.org/manual/#creating-a-checker

Best,
cu, WMD.
> --
> You received this message because you are subscribed to the Google Groups "checker-framework-gsoc" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to checker-framework...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/checker-framework-gsoc/c03f8fe4-bfb6-400b-a541-1154d56c41aao%40googlegroups.com.



--
https://ece.uwaterloo.ca/~wdietl/
Reply all
Reply to author
Forward
0 new messages