apparmor

mirror of https://gitlab.com/apparmor/apparmor synced 2025-08-22 01:57:43 +00:00
(11:00:59 AM) jjohansen: sarnold, sbeattie, cboltz, georgiag, mbelair, rlee287, iskunk: meeting time
(11:01:05 AM) ***georgiag is here
(11:01:15 AM) ***cboltz hides
(11:01:26 AM) mbelair: Hello !
(11:01:37 AM) rlee287: Hello
(11:02:37 AM) jjohansen: wfm
(11:02:50 AM) jjohansen: I will start with a status update
(11:03:47 AM) jjohansen: unfortunately we didn't get a PR into 6.16, due to a few issues that I wasn't able to resolve
(11:04:11 AM) jjohansen: I have some fixes but I am still working on at least 3 issues
(11:04:26 AM) jjohansen: 1. is af_unix backwards compat
(11:04:40 AM) jjohansen: 2. is a memory issue. Partially fixed
(11:05:06 AM) rlee287: This is the memory leak issue you were talking about earlier, right?
(11:05:21 AM) jjohansen: 3. is a network permission regression, but that might be related to 1
(11:05:30 AM) jjohansen: yes
(11:06:27 AM) jjohansen: I still want to pull in a couple other things, that are currently pending for 6.17
(11:06:52 AM) jjohansen: but it does mean some stuff is going to get pushed off further
(11:09:41 AM) jjohansen: user space side, I cut a 4.1.1 release yesterday, there are still a few known issues, but it is a large enough set of fixes since 4.1.0 that it needed to get done, and the known issues will just have to wait for 4.1.2
(11:10:01 AM) jjohansen: I still have to do release notes, etc. so not announced yet
(11:10:23 AM) sbeattie: ack, thanks
(11:10:33 AM) jjohansen: 5.0-alpha1 will be cut some time late this week or early next
(11:11:13 AM) jjohansen: I am currently focusing on getting the kernel issues resolved first
(11:12:50 AM) jjohansen: oh 4..1.2 is currently only a gitlab tarball, I can do the lp tarball but I was going to leave it until after the release notes are done
(11:13:10 AM) rlee287: How much of a difference would there be between the two tarballs?
(11:13:12 AM) jjohansen: make that 4.1.1
(11:13:37 AM) rlee287: Is the difference something I need to worry about for packaging stuff?
(11:13:53 AM) jjohansen: its not huge. the lp tarballs do some of the setup work first
(11:14:34 AM) jjohansen: rlee287: no, you have been using the gitlab tarballs, if you had been using the lp tarballs there would have been a bit of work
(11:14:50 AM) rlee287: Thanks for confirming
(11:14:53 AM) jjohansen: to switch over to gitlab
(11:16:07 AM) jjohansen: I think that is all I have for status
(11:16:24 AM) jjohansen: anyone else with status updates before we move to the agenda items
(11:16:48 AM) rlee287: Plucky SRU with profile bugfixes still in flight
(11:17:04 AM) rlee287: Questing upload of a 4.1.1 based release coming soon
(11:20:59 AM) jjohansen: alright lets move to the agenda
(11:21:34 AM) jjohansen: I still haven't done - policy layout continued. How to handle /etc/apparmor.d and subdirs
(11:21:41 AM) jjohansen: so punt to next meeting
(11:22:11 AM) jjohansen: - file policy rule order consistency. perms first or last 
(11:23:05 AM) jjohansen: I think we should punt on this one too, there will be some new rule conditionals etc coming soonish that might help inform the discussion
(11:25:46 AM) jjohansen: rlee287: Review of a draft CONTRIBUTING.md 
(11:26:02 AM) rlee287: No further comment on my end; any comments/thoughts from other people?
(11:27:36 AM) jjohansen: it is at https://gitlab.com/apparmor/apparmor/-/merge_requests/1457
(11:29:47 AM) cboltz: looks good in general, but I wonder if we should make the version requirements a bit less ancient
(11:30:39 AM) rlee287: We might be able to move to C++14 pending testing on Ubuntu Xenial (the oldest version that we (on the Ubuntu side) are trying to keep compatibility for)
(11:30:42 AM) cboltz: I assume the MR basically affects 5.0 (not 4.x) - do you really think someone wants to use 5.0 with python 3.5?
(11:30:56 AM) jjohansen: cboltz: there is a lot of tension in the version requirements, we need to be able to pull stuff back to quite old systems
(11:31:28 AM) jjohansen: the requirement could be a bit looser from the python side than the core
(11:32:10 AM) jjohansen: core = just bare minimum to build and load policy
(11:35:14 AM) jjohansen: cboltz: can you comment on the MR with what version of python you think is reasonable
(11:37:01 AM) cboltz: good question - I'm not sure if I have a list of features per python version
(11:38:14 AM) jjohansen: so we certainly some guideline on what can be used
(11:39:16 AM) jjohansen: I am inclined to leave it at the current 3.5 unless someone proposes something else
(11:39:43 AM) jjohansen: it doesn't have to be now, comments/suggestions can be added any time
(11:39:55 AM) jjohansen: but I think we should get this sorted for next meeting
(11:40:37 AM) georgiag: is there anything else to be done to leave "draft" status? other than agreeing on the versions
(11:40:59 AM) jjohansen: I don't think so
(11:41:43 AM) rlee287: Going to want to do another lookover once we have versions agreed, at any rate
(11:41:47 AM) rlee287: Just to check for typos, etc.
(11:41:52 AM) rlee287: But nothing major I can think of
(11:42:37 AM) georgiag: ack, thanks
(11:43:04 AM) jjohansen: okay, please add comments before next meeting
(11:43:09 AM) cboltz: match/case was added in python 3.10 - having that might be nice, but I'm not sure if it's worth that big version bump
(11:43:56 AM) jjohansen: how old is 3.10
(11:43:57 AM) rlee287: I deliberately went through and tore out match/case at one point for the backwards compatibility reason
(11:44:21 AM) jjohansen: how likely is it to be backported to different distro releases
(11:44:44 AM) mbelair: Python 3.10 is from october 2021
(11:45:11 AM) jjohansen: more importantly what are we saying we can support time wise in the python utils
(11:45:47 AM) jjohansen: eg. only being able to drop current into something that is 4 years old is, not ideal
(11:46:27 AM) mbelair: (python 3.10 is in jammy, not focal)
(11:47:13 AM) jjohansen: but, perhaps it might be worth looking at the cost of containerizing the tools for something that old if there are features that are worth it
(11:48:09 AM) rlee287: mbelair: focal is now in ESM, for the record
(11:48:59 AM) rlee287: Last time I went through the code I vaguely remember there being format strings (Python 3.6, easily replacable) and a specific time/date method (Python 3.7, could polyfill if we wanted to keep it)
(11:49:19 AM) cboltz: how likely is it that someone wants to use AppArmor git master or 5.0 (once it's ready) on focal?
(11:50:11 AM) ***cboltz would guess that such old releases get bug-specific backports of patches
(11:50:38 AM) jjohansen: bugfix backports happen but are rare
(11:51:22 AM) mbelair: jjohansen: If that is not too costly, I think that could be interesting to have a more recent python version , some features can really simplify code, f-string, walrus operator, match, pipe unions are good examples
(11:51:23 AM) jjohansen: with that said, the parser/core is getting pulled all the way back to 16.04 atm
(11:51:47 AM) rlee287: 16.04=Xenial
(11:52:40 AM) jjohansen: mbelair: can you make a proposal, add a comment.
(11:53:10 AM) mbelair: jjohansen: ok
(11:53:27 AM) jjohansen: the question becomes whether tooling is going to get pulled back, and whether it can be containerized
(11:53:34 AM) cboltz: whatever version we choose, can we please setup CI to test with that version to avoid that too-new things sneak in?
(11:54:11 AM) rlee287: Agreed that we should definitely do that
(11:54:35 AM) jjohansen: from the Canonical side, that would mean snap, and I am not sure what that means for python
(11:54:40 AM) jjohansen: something to investigate
(11:55:38 AM) jjohansen: well we can try, but setting CI for new things is a game of whack-a-mole that people will have to try and keep up with
(11:56:50 AM) jjohansen: so from snaps side, its not part of the core, so the snap would vendor its own version
(11:57:08 AM) jjohansen: flatpaks, I need to investigate more
(11:59:55 AM) jjohansen: well lets investigate, and add comments
(12:00:03 PM) jjohansen: moving on for now
(12:00:05 PM) jjohansen: request to use file extension on profile names (maybe .apparmor) to make it easier for external tooling to know/understand what the files are for.
(12:00:30 PM) jjohansen: are we ready to vote?
(12:00:41 PM) jjohansen: https://gitlab.com/apparmor/apparmor/-/issues/489
(12:01:04 PM) rlee287: Only for the extension for new profiles
(12:01:29 PM) rlee287: Haven't made up my mind yet about profile includes (no extension, different extension, same extension)
(12:01:39 PM) rlee287: What about the rest of you?
(12:03:08 PM) jjohansen: interesting question about includes
(12:04:19 PM) jjohansen: if this is being done to ease tooling (it is), then a different suffix for units that don't stand on their own makes sense
(12:05:21 PM) cboltz: with this reason, it might even make sense to have different extensions for preamble includes (variable definitions) and in-profile includes (abstractions)
(12:06:31 PM) cboltz: (that said - so far aa-* tooling is based on directory structure/names, which works quite well)
(12:07:44 PM) jjohansen: I would really, really like to get away from the distinction between preamble includes and abstractions
(12:08:13 PM) jjohansen: abstractions need to be able to specify their dependencies, whether via include or another mechanism
(12:09:30 PM) cboltz: today they do this by error message "undefined variable @{foo}" ;-)  - interpreting that as a dependency should be doable
(12:10:21 PM) cboltz: still, variable definitions need to go into the preamble (unless we allow them inside a profile)
(12:11:17 PM) jjohansen: yes that is a goal
(12:12:02 PM) jjohansen: with that said, we need to be careful, you don't just want to overlay everything either
(12:12:47 PM) cboltz: I foresee an interesting can of worms, for example, do variable definitions have to be at the beginning of the profile, or are they allowed in the middle of it?
(12:14:17 PM) cboltz: (not really related to filename extensions, of course)
(12:15:09 PM) Talkless left the room (quit: Quit: Konversation terminated!).
(12:15:21 PM) jjohansen: so
(12:16:30 PM) jjohansen: 1. I was thinking of adding a dependency keyword that would allow includes to specify an include they depend on, whether we use that to suck it in or just error out and make the author fix their profile ...
(12:16:43 PM) jjohansen: 2. variable just has to be defined before use
(12:17:25 PM) rlee287: Between these two I'd be in favor of 2
(12:17:28 PM) jjohansen: obviously head of profile makes it easy, but we have other cases, where before use is happening in the preamble where one var is used to define another
(12:17:56 PM) jjohansen: rlee287: as in fix their profile?
(12:18:05 PM) rlee287: Yeah
(12:18:27 PM) jjohansen: I think that is generally the right approach, because of the next
(12:18:46 PM) georgiag: agreed
(12:19:13 PM) jjohansen: 3. variables can be scoped to the local block, we are already doing this for the automatically generated profile_name, exec_name, attachment ...
(12:19:51 PM) jjohansen: so an include in a block, might be different than say in the preamble
(12:20:13 PM) jjohansen: makes auto resolving intent on a depends "fun"
(12:20:52 PM) jjohansen: still want the depends, and possibly tooling to ask where do you want the include
(12:21:02 PM) jjohansen: default would probably the preamble
(12:21:02 PM) cboltz: it also makes debugging of profiles fun if an abstraction overwrites a variable the profile defines in the preamble
(12:21:15 PM) jjohansen: right
(12:21:24 PM) jjohansen: being explicit is better
(12:24:02 PM) jjohansen: so getting back to the original question
(12:24:21 PM) jjohansen: I think having 2 extensions makes sense
(12:24:37 PM) jjohansen: an argument can be made for 1 or 3 :)
(12:24:57 PM) rlee287: I'm strongly against 1 but am open to an argument for 3 if someone wants to open up one
(12:25:37 PM) minimal left the room (quit: Read error: Network is unreachable).
(12:26:00 PM) minimal [~minimal@0002b71e.user.oftc.net] entered the room.
(12:27:22 PM) jjohansen: so I think we need to update the issue with proposals for the other extension
(12:27:49 PM) jjohansen: maybe .aai .aainclude .aaabstraction, ...
(12:27:57 PM) rlee287: Do we want to vote now on the extension for main profiles themselves?
(12:28:11 PM) rlee287: Or do we want to punt and vote on both extensions simultaneously next time
(12:28:22 PM) jjohansen: either works for me
(12:29:12 PM) georgiag: I'd prefer to vote for both at the same time
(12:29:55 PM) minimal left the room (quit: Read error: Network is unreachable).
(12:30:14 PM) minimal [~minimal@0002b71e.user.oftc.net] entered the room.
(12:30:26 PM) jjohansen: so I should say, that the decision around having a single or multiple probably changes how I vote, so it does make sense to do them at the same time
(12:37:51 PM) cboltz: ok, so we'll vote at the next meeting
(12:37:55 PM) cboltz: next topic? ;-)
(12:38:29 PM) jjohansen: rlee287: proposal for re"actual_regex" syntax to allow for things like re"/proc/[1-9][0-9]*/[^/]+" r using the full (non-backtracking) regex expressiveness while keeping the existing AARE usage as-is
(12:38:37 PM) jjohansen: https://gitlab.com/apparmor/apparmor/-/issues/490
(12:38:55 PM) jjohansen: the proposed syntax still bothers me
(12:39:19 PM) rlee287: Have you figured out an explanation for why it bothers you?
(12:39:23 PM) rlee287: Or is it still a gut feeling
(12:39:53 PM) jjohansen: one of the issues is how it fits in with the other rules
(12:40:25 PM) jjohansen: eg. dbus method="foo*",
(12:40:37 PM) jjohansen: dbus method=re"foo.*",
(12:41:04 PM) jjohansen: I really don't like how that
(12:41:48 PM) cboltz: indeed, it looks strange
(12:41:56 PM) jjohansen: the re hard against the " " also feels strange
(12:42:17 PM) rlee287: Personally I see it as very similar to the Python r"..." raw string syntax
(12:42:19 PM) jjohansen: re."foo" or something like that feels better
(12:42:27 PM) rlee287: With re standing for regex in this case
(12:42:42 PM) rlee287: Not opposed to re."foo" if that's something other people like more
(12:42:56 PM) jjohansen: not saying it should be . just that the re the " with nothing feels like the quote was just put in the wrong place
(12:43:47 PM) jjohansen: yeah, thats another problem. I have never liked the python syntax for that :)
(12:43:56 PM) cboltz: do we also want to allow regexes in the middle of a path, like   /usr/bin/re".*" r,   ?
(12:44:29 PM) rlee287: I would not want to allow that
(12:44:47 PM) rlee287: To instead have re"/usr/bin/.* r," or whatever prefix we decide to use instead of re
(12:46:14 PM) cboltz: for the syntax - would something like   </usr/bin/.*>   be an option? (I'm aware we already have   include <...>   but I don't think that's a  big problem)
(12:46:44 PM) roddhjav: I think we need to allow thing like /usr/bin/re".*" r,. Because this would allow using regex in variable.
(12:46:54 PM) ***rlee287 checks to see if angle brackets are already a regex thing
(12:47:10 PM) rlee287: OK they're not
(12:47:26 PM) rlee287: But I'd still like something that's tied a bit more closely to the name "regex"
(12:47:49 PM) rlee287: roddhjav: wouldn't it be possible to do @{var}=abc re."def.+" ?
(12:47:58 PM) rlee287: Or am I missing something
(12:48:30 PM) jjohansen: so, using < > would break some existing parse
(12:50:11 PM) jjohansen: it would be possible to use the proposed syntax in vars
(12:50:38 PM) roddhjav: rlee287: That would be nice to have yes. Thus we should also be able to write something like: @{bin}/@{var}. Where @{bin} is the existing bin var (that uses glob)
(12:51:16 PM) rlee287: Right, but I don't see why that would require allowing the regex prefix in the middle of an AARE literal
(12:51:25 PM) jjohansen: yeah, as long as it is consistent within the unit. I think we can handle switching internally
(12:51:50 PM) roddhjav: ack, good for me them
(12:51:57 PM) roddhjav: then*
(12:52:26 PM) jjohansen: so what I meant by that is for any given var element it stays consistent in re or glob, then it shouldn't matter what variable it embeds
(12:55:51 PM) cboltz: the tools internally expand variables to   {item1,item2}   and then matches paths against the expanded variables, so I foresee some "fun" ;-)  - but that's not a reason to block this feature
(12:56:39 PM) rlee287: It expands into strings and then parses as opposed to attaching syntax trees after parsing? Interesting
(12:57:59 PM) cboltz: to make it even more interesting - in the end, the rules get converted to regexes
(12:58:12 PM) cboltz: which are then used to match a path from a log event against the rule
(12:58:35 PM) rlee287: Ah, right
(12:59:21 PM) cboltz: these are internal details, but means that the tools technically will need to support something like   /foo/{re".*",bar}
(12:59:33 PM) cboltz: (yes, that will probably be interesting to implement ;-)
(12:59:50 PM) georgiag: if by interesting you mean nightmare, then sure
(12:59:56 PM) georgiag: :)
(01:00:04 PM) cboltz: right, I forgot the [tm] ;-)
(01:00:19 PM) rlee287: f u n for everyone :p
(01:01:17 PM) jjohansen: with a little work we could export a lib interface to handle that. do the parse to a tree and output an re from the tree
(01:02:45 PM) georgiag: I also wonder about the case where an re string contains a variable... 
(01:02:58 PM) georgiag: but details are for implementation I guess
(01:03:14 PM) cboltz: georgiag: scaring people with corner cases is my job ;-)
(01:03:52 PM) georgiag: cboltz: always unironically appreciated 
(01:04:31 PM) cboltz: jjohansen: I'd even take a function that matches a path (from the log) against a path from a profile (which might contain AARE or re"...") and just returns true/false
(01:05:37 PM) cboltz: (just as an alternative idea)
(01:06:39 PM) jjohansen: sure. I think we are getting to where we can give you some, or maybe even all of that
(01:08:10 PM) jjohansen: so assuming we go with re
(01:08:42 PM) jjohansen: 1. do we have a break between the re and "  ie.  re.""  or some other character
(01:09:36 PM) jjohansen: 2. do we are that   method=re."foo"  looks a little odd
(01:10:18 PM) jjohansen: 3. do we care that re"foo" breaks some corner cases of parse, that likely don't exist n the wild
(01:10:41 PM) rlee287: For 1) I have no opinion, and for 2) I don't see anything strange about a specifier like method=re."foo"
(01:10:45 PM) jjohansen: and if they do, are likely bugs in profiles
(01:10:51 PM) rlee287: What kind of corner cases are you thinking about for 3)?
(01:11:16 PM) jjohansen: re"foo" can be parsed as two tokens in some cases
(01:11:20 PM) jjohansen: re and "foo"
(01:11:40 PM) cboltz: I'd add   4. do we really need the quotes?
(01:11:52 PM) jjohansen: in other cases it can be treated as a single token
(01:12:05 PM) jjohansen: its messed up
(01:12:16 PM) jjohansen: yes
(01:12:37 PM) jjohansen: that is 4. yes we need quotes or another special character
(01:12:42 PM) jjohansen: re.foo
(01:12:55 PM) jjohansen: is very much a valid match string currently
(01:13:00 PM) rlee287: The quotes/some other symbol are absolutely needed to prevent e.g. released from being interpreted as re (leased) -> leased
(01:14:19 PM) cboltz: well, having a special character after re (like the dot or a colon) should prevent that
(01:14:40 PM) rlee287: But we'd still need some kind of terminator character to end the regex
(01:14:53 PM) cboltz: another crazy syntax idea - what if we abuse/extend the variable syntax and let regexes look like variable names?   @{re:.*}
(01:15:42 PM) cboltz: for terminating character - I'd apply the same rule as for AARE: it ends at the space (unless it's quoted)
(01:20:26 PM) cboltz: for the variable-like syntax, I could also imagine   @(.*)   (note () vs {}) - that could in theory conflict with existing rules, but it's unlikely that such rules/paths exist in the wild
(01:21:52 PM) cboltz: an advantage would be that it can be embedded inside a path like   /foo/@(.*)   - which we already plan to allow via variables, so why not allow it without that workaround?
(01:22:35 PM) rlee287: Would you like to write up this proposal under the Gitlab issue (https://gitlab.com/apparmor/apparmor/-/issues/490)?
(01:22:57 PM) cboltz: yes, I can do that later
(01:24:52 PM) rlee287: I think at this point we should wrap up this discussion about the syntaxes and think over the proposals for next time
(01:24:59 PM) rlee287: Unless anyone else has any quick comments
(01:25:08 PM) cboltz: agreed
(01:27:34 PM) jjohansen: the only other thing I have, is to ask people to dump needs/requirements around splitting the profiles/policy from the rest of the project
(01:27:58 PM) rlee287: Right, which is something we'd like to do sooner rather than later
(01:29:07 PM) jjohansen: you can dump comments etc in https://gitlab.com/apparmor/apparmor/-/issues/523
(01:29:13 PM) roddhjav: Well, on this specific subject, I think I can help you on this... 
(01:29:31 PM) jjohansen: yes, but it isn't going to happen before next meeting
(01:29:33 PM) cboltz: I understand the idea, but things like @{profile_name} still makes profiles version-specific
(01:30:10 PM) jjohansen: yes to a point
(01:30:54 PM) jjohansen: there will be dependencies, but long term its the right move
(01:31:13 PM) jjohansen: the goal is to be able to deal with most of the dependencies by conditionals etc
(01:31:16 PM) roddhjav: We can discuss this, but the "reference policy" project could easilly support multiple abi version. Apparmor.d already does it.
(01:31:23 PM) jjohansen: we will still have release branches
(01:31:43 PM) jjohansen: yes
(01:32:38 PM) georgiag: I'm currently working on improving our policy conditionals, so that can help with that too
(01:32:46 PM) jjohansen: basically we are doing a lot of work, to try and fix conditionals, and variable etc, so that most of the things apparmor.d is doing to support multiple distro/releaes are handled natively
(01:33:20 PM) jjohansen: the parser is going to a export a bunch of variables etc too
(01:33:58 PM) jjohansen: yes there will be some issues, especially at first but the goal is to get to a consistent reference policy
(01:33:59 PM) rlee287: The one thing that comes to mind is how we would track minimum parser versions in the profiles repo
(01:34:13 PM) rlee287: Right now the parser in the repo should be able to parse the profiles in the repo
(01:34:23 PM) rlee287: But when they get split we no longer have that obvious sync method
(01:34:45 PM) jjohansen: sure
(01:35:13 PM) jjohansen: I think it will be something along the lines of keeping the major release numbers in sync
(01:35:36 PM) jjohansen: doing major releases at the same time, and letting the point releases drift
(01:36:15 PM) jjohansen: but even long term, that shouldn't be necessary because profiles will be able to check the parser version
(01:36:36 PM) jjohansen: and even check if a feature exists
(01:36:54 PM) rlee287: Well, "profiles will be able to check the parser version" still necessitates handling of the cases where the parser is old enough not to support that kind of feature testing
(01:37:11 PM) rlee287: Once the relevant features land to enable those checks
(01:41:01 PM) roddhjav: > doing major releases at the same time, and letting the point releases drift
(01:41:01 PM) roddhjav: Well, yes and no. The profiles are not individual profile, they are very deeply linked together implementing a security requirement. Thus this implementation can change a lot with time (I have rewritten 3 times the systemd profiles set). Meanwhile some profiles are only trying to separate privileges as much as possible, and thus they won't change a lot.
(01:42:02 PM) jjohansen: rlee287: right, policy by necessity drifts over time. Every time we add a new feature, as soon as you use it, you break old parsers/releases
(01:42:27 PM) jjohansen: so atm we are working on adding the feature that will eventually help fix that problem
(01:42:47 PM) jjohansen: but in the short term, we are still going to have to keep in sync
(01:43:02 PM) jjohansen: so a 5.0 policy 5.0 userspace
(01:43:16 PM) jjohansen: ...
(01:43:25 PM) roddhjav: There is also the case where upgrade version of software change the profile a lot with for instance internall sandboxing (bwrap, landlock) or when they move part of the software to other external components.
(01:43:46 PM) jjohansen: I assume even, 5.1, 5.1 and at first only the bug fix version will drift
(01:44:42 PM) jjohansen: roddhjav: indeed good point, which we are not tracking at all atm. But again conditionals etc ...
(01:45:39 PM) cboltz: I hope you don't want profiles that first call   rpm -q $package   ;-)
(01:45:41 PM) jjohansen: its going to take a lot of work to get to where we want to be
(01:46:27 PM) jjohansen: :)
(01:48:25 PM) jessfraz left the room (quit: Remote host closed the connection).
(01:49:26 PM) jessfraz [~jessfraz@syn-076-086-246-048.res.spectrum.com] entered the room.
(01:50:50 PM) rlee287: OK: anything else we want to discuss today?
(01:51:26 PM) jjohansen: I don't have anything more
(01:51:28 PM) cboltz: nothing from me
(01:51:39 PM) georgiag: nothing from me
(01:52:24 PM) jjohansen: thanks everyone, next meeting is scheduled for July 8, 18:00 utc
(01:52:24 PM) jjohansen: meeting adjourned