{"action":"created","issue":{"url":"https://api.github.com/repos/sparkle-project/Sparkle/issues/962","repository_url":"https://api.github.com/repos/sparkle-project/Sparkle","labels_url":"https://api.github.com/repos/sparkle-project/Sparkle/issues/962/labels{/name}","comments_url":"https://api.github.com/repos/sparkle-project/Sparkle/issues/962/comments","events_url":"https://api.github.com/repos/sparkle-project/Sparkle/issues/962/events","html_url":"https://github.com/sparkle-project/Sparkle/issues/962","id":197898784,"number":962,"title":"Remaining leftover changes from my fork","user":{"login":"zorgiepoo","id":857267,"avatar_url":"https://avatars.githubusercontent.com/u/857267?v=3","gravatar_id":"","url":"https://api.github.com/users/zorgiepoo","html_url":"https://github.com/zorgiepoo","followers_url":"https://api.github.com/users/zorgiepoo/followers","following_url":"https://api.github.com/users/zorgiepoo/following{/other_user}","gists_url":"https://api.github.com/users/zorgiepoo/gists{/gist_id}","starred_url":"https://api.github.com/users/zorgiepoo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zorgiepoo/subscriptions","organizations_url":"https://api.github.com/users/zorgiepoo/orgs","repos_url":"https://api.github.com/users/zorgiepoo/repos","events_url":"https://api.github.com/users/zorgiepoo/events{/privacy}","received_events_url":"https://api.github.com/users/zorgiepoo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2016-12-28T18:49:03Z","updated_at":"2016-12-28T21:29:59Z","closed_at":null,"body":"Here I'll keep an update a track of a list of some \"small\" changes from my fork that *could* possibly be made. I may not have much time left so this is what I want to focus on. Let me know what you think should or should not be addressed in the near future.\r\n\r\n* Expect the `length` attribute for appcast items to exist.\r\n   * Warn if the attribute is not specified (a fair number of developers leave it out)\r\n   * Use this field value instead of value from http header (what if that value is unknown?)\r\n   * Warn if the attribute != expected content value from http header (if both are available)\r\n   * Note or be aware that the download did receive responses can be received multiple times in rare cases for a single download according to the docs.\r\n* Make guided packages the default rather than interactive packages being the default for packages.\r\n   * Opt into `foo.sparkle_interactive.pkg` or `foo.sparkle_interactive.mpkg`\r\n   * Interactive installations have real problems (lack of success status handling, strange task spawning code) and worse user experience.\r\n   * Some developers unpleasantly ship e.g. `foo.sparkle_guided.pkg` for their website distribution.\r\n* Remove the old application instead of moving the old application to the trash (#827)\r\n   * Not seamless: clutters user's Trash; Sparkle is the only updater that does this.\r\n   * More inefficient across volumes potentially, strange issues (#752)\r\n   * Moving old app to trash may not always be possible/easy in my fork (I think, regarding running as root).\r\n   * Could make atomic-safe directory replacements more difficult in the future with APFS\r\n   * Would cause removal of some code\r\n* Don't ask for update permission after 3 (or x) number of hours, instead of 2nd launch\r\n   * 2nd launch is a poor metric; user could launch application more than once in a short period of time.\r\n   * In my fork where support for updating *other* bundles is improved, the lifetime of the updater and bundle to update are distinct, and the updater be started up repeatably and not ran for long (e.g. `sparkle-cli`)\r\n* Rewritten `SULog()` usage\r\n   * Let us stick with reporting errors for the time being. We shouldn't be logging information unless something unexpected happen (i.e, don't always log when extracting update).\r\n   * A global file location (in master) to write logs is not a good idea. It is rewritten when multiple applications are using Sparkle simultaneously, and when multiple processes are using `SULog()` simultaneously (very common in my fork). Always writes to disk.\r\n   * Should take leverage of Apple's logging APIs; my fork uses ASL APIs currently. 10.12 introduced a new logging API that I haven't looked into yet.\r\n   * Need to verify how system logging has changed in 10.12 and how if that affects Sparkle.\r\n* Add ability for `SUHost` to reload the Info dictionary (bypassing NSBundle cache)\r\n   * My fork improves being able to update other bundles, so master is not that affected.\r\n   * Need to verify the correctness of the current code in my fork.\r\n* Rewrote termination listener code in my fork\r\n   * It is daemon safe and doesn't use AppKit\r\n   * The code is more complex. Not necessarily an urgent need to merge into master right now.\r\n* Obj-C type generic annotations (unless we support old old versions of Xcode?)\r\n* Add AppKit prevention guards to implementation files where possible\r\n\r\nChanges that are too big:\r\n\r\n* Add an installation type tag to the appcast items, which is mandated if the installation will be a package type install.\r\n   * My fork needs to know what type of package installation it is to see if authorization is necessary (the type is later validated against the install type that was found in the archive since the feed is untrusted)\r\n   * master currently suffers from a potential issue of thinking an install can be automatically downloaded/installed in the background when encountering package installs. Likely a rare issue however because app is most likely in a location not writable by user (that the initial package installer placed it at)\r\n* Merging the automatic and manual update alert windows/nibs\r\n   * Required major re-architecturing for the internal update drivers logic.\r\n* The launchd, XPC, UI user driver changes, update driver changes, automatically installing update if app terminates.. etc, all other major changes."},"comment":{"url":"https://api.github.com/repos/sparkle-project/Sparkle/issues/comments/269543842","html_url":"https://github.com/sparkle-project/Sparkle/issues/962#issuecomment-269543842","issue_url":"https://api.github.com/repos/sparkle-project/Sparkle/issues/962","id":269543842,"user":{"login":"pornel","id":72159,"avatar_url":"https://avatars.githubusercontent.com/u/72159?v=3","gravatar_id":"","url":"https://api.github.com/users/pornel","html_url":"https://github.com/pornel","followers_url":"https://api.github.com/users/pornel/followers","following_url":"https://api.github.com/users/pornel/following{/other_user}","gists_url":"https://api.github.com/users/pornel/gists{/gist_id}","starred_url":"https://api.github.com/users/pornel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pornel/subscriptions","organizations_url":"https://api.github.com/users/pornel/orgs","repos_url":"https://api.github.com/users/pornel/repos","events_url":"https://api.github.com/users/pornel/events{/privacy}","received_events_url":"https://api.github.com/users/pornel/received_events","type":"User","site_admin":false},"created_at":"2016-12-28T21:29:59Z","updated_at":"2016-12-28T21:29:59Z","body":"@jkbullard I don't mean that authoritative is secure and bulletproof, but rather that by design it's the source of that information (whether it's sent by the author or attacker).\r\n\r\nWe don't sign appcasts and don't intend to, so for Sparkle length in HTTP response headers and HTTP response body is equally (in)secure, but the latter can be accidentally invalid, while the former can't be accidentally invalid.\r\n\r\nNote also that we (and Apple via ATS) strongly urge to use HTTPS, which protects response length.\r\n"}}
{"actor":{"display_login":"pornel"}}