Good first issues

[maxgoedjen]

Spitting this conversation off from #492 (comment)

[maxgoedjen]

@PBHDK to be perfectly honest I haven't done a great job of tagging "good first issues" – part of that is that Secretive is just kind of a weird project in a lot of ways – my goals with it are for it to be a fairly small focused/auditable app, which precludes a lot of "well it'd be cool if X" type development that might be more appealing in a "regular" app.

For you specifically, I'd be curious to know what kind of work you'd be interested in contributing? Nitty-gritty agent stuff, UI, etc? I'm pretty sure I have some smallish "needs improvement/fixes" type stuff in whatever domain.

[paulhdk]

@PBHDK to be perfectly honest I haven't done a great job of tagging "good fi`rst issues" – part of that is that Secretive is just kind of a weird project in a lot of ways – my goals with it are for it to be a fairly small focused/auditable app, which precludes a lot of "well it'd be cool if X" type development that might be more appealing in a "regular" app.

And that’s more than fair, @maxgoedjen!

For you specifically, I'd be curious to know what kind of work you'd be interested in contributing? Nitty-gritty agent stuff, UI, etc? I'm pretty sure I have some smallish "needs improvement/fixes" type stuff in whatever domain.

I’m open to anything! Maybe just to give you some background, I’m currently taking a course at my university where we get to work on open source (which is great!), and for the remaining weeks, I thought Secretive would make a great “excuse” to get some coursework done and brush up my Swift skills. So, I’ll take what I can get issue-wise :-)

[paulhdk]

This is great, thanks @maxgoedjen! See my comments below.

Maybe just to give you some background, I’m currently taking a course at my university where we get to work on open source (which is great!), and for the remaining weeks, I thought Secretive would make a great “excuse” to get some coursework done and brush up my Swift skills. So, I’ll take what I can get issue-wise :-)
Cool! If you're interested in some deep-ish debugging:

I've been having a hell of a time reproducing this one. If you're able to reproduce it, it'd probably be a good moderate complexity exercise.
#378

I've been able to reproduce this one, but haven't had any success fixing yet. I've been playing with some ideas (in thread) but haven't found a good solution yet.
#372

Given that even you've run into problems with both, I would value my immediate chances of success to be quite low. So, I would deprioritise both of those for now in favour of making some porgress on the keychain-backed settings if that makes sense?

I haven't specced it out yet, but one other idea I've been kicking around but haven't gotten to yet: keychain-backed settings for the app. In broad pieces (it's a lot, if you're interested in some of this we can chat about breaking off chunks):

Breaking off chunks sounds like a great start.

A backing store – it'd just be vanilla keychain, not SEP, but basically just a SettingsStore for key/value settings. Something along the lines of UserDefaults just backed by the keychain so other apps can't tamper with it. There's probably some nicer API design there that could be done too, but I'd be inclined to keep it simple.

Step 1: enable keychain-backed settings.

What should it be storing right now?

Settings Screen UI
Probably moving the config/agent install stuff into that page?
Maybe setting for public key "comment" (the GitHub@secretive.Max’s-MacBook-Pro.local bit at the end of the public key). I've had some requests for different formats over the years – might make sense to have a couple fixed options, or maybe some https://developer.apple.com/design/human-interface-guidelines/token-fields based format?
Maybe setting for public key file location? Gotten some requests for placing it at ~/.ssh/ which would require some selection of the path to allow sandboxing to work with it.

Step 2: UI for the keychain-backed settings
Step 3: Move SecretAgent configuration in the new settings page.
Step 4: add ability to customise the public key comment format to the new settings page.

Do you agree with the steps?

[paulhdk]

Hi @maxgoedjen !

Just giving this thread a polite bump 🙂
I don't want to create any stress where there doesn't need to be any, but I am working against a deadline with my university course, so I would love your input on the above if possible. I have already started working on the settings screen UI, but want to avoid running in the wrong direction.

[maxgoedjen]

Crap sorry about that, read it and mentally composed a reply and then just forgot 🤦

I think broadly 1 and 2 sound good. For 3, let's just add an extra button to get to that page vs full setup flow (or maybe embed it there or something – might need some playing around with to see what feels good). 4 sounds good.

[paulhdk]

Hi @maxgoedjen

A backing store – it'd just be vanilla keychain, not SEP, but basically just a SettingsStore for key/value settings. Something along the lines of UserDefaults just backed by the keychain so other apps can't tamper with it. There's probably some nicer API design there that could be done too, but I'd be inclined to keep it simple.

I'm making progress here and hope to have an RFC pull request ready tomorrow. Just to confirm, would you want the SettingsStore to replace all existing uses of UserDefaults? The ones I'm seeing here are com.maxgoedjen.Secretive.updater.ignorelist and com.maxgoedjen.Secretive.lastBuild.

If no, what is being stored in UserDefaults, and what is being stored in SettingsStore?

[maxgoedjen]

@PBHDK I'd say don't worry about the preexisting items for now – I might end up migrating those eventually but I think that'll require some thinking on my part about how to do that. For now let's just stick with the properties we mentioned in earlier discussions.