Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Will Stanton via swift-corelibs-dev]

Hello Tony,

Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my 
desktop-less server, and I think many processes still have their own save 
locations.
Still, I can believe its used in a lot of places 
(https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed 
to it!

Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and 
format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?


What about the path for cookies+caches?

Regards,
Will Stanton

> On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Off-list, someone pointed me here:
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> and here:
> 
> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
> 
> Noting that there seems to be a growing consensus for $HOME/.config.
> 
> Is this spec beginning to be used in the real world?

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Itai Ferber via swift-corelibs-dev]

>From my (potentially limited) experience, I would say that yes, many tools out 
>there do follow this spec.
I only have anecdotal evidence to back this up, but I think many new tools use 
this convention, and those that don't do not out of long-standing conventions 
that say otherwise (e.g. `~/.vimrc`, `~/.emacs.d`, etc.). Someone with more 
immediate access to a Linux box can maybe help back this up.

I personally like this convention, and think it's a safe option. We are highly 
unlikely to conflict with anything in `~/.config` or `~/.local`.

On 14 Nov 2016, at 11:37, Tony Parker via swift-corelibs-dev wrote:

>
>> On Nov 14, 2016, at 10:47 AM, Will Stanton  wrote:
>>
>> Hello Tony and Philippe,
>>
>> I don’t think it would be odd for cookie/setting files to be in a folder 
>> named after Foundation (namely ~/.foundation):
>> - The files are owned by Swift/Linux Foundation in the sense Foundation 
>> writes them, and Foundation is the only one that should access them 
>> directly. Foundation should enforce security.
>> - On macOS, settings seem to be written to 
>> ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed 
>> ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
>> ‘.foundation’ is used in lieu of a library directory, and I feel this is 
>> acceptable so as not to clash with any user ~/Preferences or ~/Library 
>> directory.  I am OK with the ‘Foundation ownership’ per above.
>> And, executable name seems reasonable in lieu of bundle ID.
>>
>> I noted something like 
>> ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to 
>> keep symmetry/reuse more CF code, but changing Swift CF is probably 
>> necessary anyway and better (fewer search paths to loop through, possibly 
>> less I/O).
>>
>
> Agreed, I don’t have any problem with baking a set of rules into CF that is 
> specific to various platforms. That’s it’s job after all.
>
>>
>> Am interested in alternatives of course :-)
>> - But having separate folders for each app seems complicated, ex. 
>> '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
>> - I don’t really mind the name of an encapsulating folder, .foundation or 
>> otherwise.
>> - Placing system configuration files in /etc is a norm, but I think I’d feel 
>> more comfortable with Swift app settings in /home/user (easier to keep track 
>> of, and I can delete the whole thing without consequences*). I’m also not 
>> writing any real low-level services in Swift… but others probably are… but 
>> they probably have their own code to write config data to /etc!
>>
>
> Off-list, someone pointed me here:
>
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> and here:
>
> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
>
> Noting that there seems to be a growing consensus for $HOME/.config.
>
> Is this spec beginning to be used in the real world?
>
> - Tony
>
>>
>> To Philippe’s points about security+future-proofing:
>> Perhaps the cookie file could be named per version of its format:
>> ~/.foundation/Cookies/shared initially
>> When we have a new format:
>> ~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name 
>> entirely?
>>
>> I also think it should be up to Swift Foundation to enforce cookie security 
>> on a per-app/family basis (the latter requires changes to the package 
>> structure?).
>> Perhaps for now, it is possible to save the hash and name of the executable 
>> storing a cookie? And Foundation can load cookie storage only if the 
>> executable name and file haven’t changed? (Is that an unnecessary pain?)
>>
>> Regards,
>> Will Stanton
>>
>>> On Nov 14, 2016, at 12:44 PM, Tony Parker  wrote:
>>>
>>> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
>>> Foundation is just one of the libraries involved? On Darwin, the prefs are 
>>> organized by application, not by framework.
>>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


signature.asc
Description: OpenPGP digital signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

> On Nov 14, 2016, at 10:47 AM, Will Stanton  wrote:
> 
> Hello Tony and Philippe,
> 
> I don’t think it would be odd for cookie/setting files to be in a folder 
> named after Foundation (namely ~/.foundation):
> - The files are owned by Swift/Linux Foundation in the sense Foundation 
> writes them, and Foundation is the only one that should access them directly. 
> Foundation should enforce security.
> - On macOS, settings seem to be written to 
> ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed 
> ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
> ‘.foundation’ is used in lieu of a library directory, and I feel this is 
> acceptable so as not to clash with any user ~/Preferences or ~/Library 
> directory.  I am OK with the ‘Foundation ownership’ per above.
> And, executable name seems reasonable in lieu of bundle ID.
> 
> I noted something like 
> ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to 
> keep symmetry/reuse more CF code, but changing Swift CF is probably necessary 
> anyway and better (fewer search paths to loop through, possibly less I/O).
> 

Agreed, I don’t have any problem with baking a set of rules into CF that is 
specific to various platforms. That’s it’s job after all.

> 
> Am interested in alternatives of course :-)
> - But having separate folders for each app seems complicated, ex. 
> '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
> - I don’t really mind the name of an encapsulating folder, .foundation or 
> otherwise.
> - Placing system configuration files in /etc is a norm, but I think I’d feel 
> more comfortable with Swift app settings in /home/user (easier to keep track 
> of, and I can delete the whole thing without consequences*). I’m also not 
> writing any real low-level services in Swift… but others probably are… but 
> they probably have their own code to write config data to /etc!
> 

Off-list, someone pointed me here:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

and here:

http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix

Noting that there seems to be a growing consensus for $HOME/.config.

Is this spec beginning to be used in the real world?

- Tony

> 
> To Philippe’s points about security+future-proofing:
> Perhaps the cookie file could be named per version of its format:
> ~/.foundation/Cookies/shared initially
> When we have a new format:
> ~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?
> 
> I also think it should be up to Swift Foundation to enforce cookie security 
> on a per-app/family basis (the latter requires changes to the package 
> structure?).
> Perhaps for now, it is possible to save the hash and name of the executable 
> storing a cookie? And Foundation can load cookie storage only if the 
> executable name and file haven’t changed? (Is that an unnecessary pain?)
> 
> Regards,
> Will Stanton
> 
>> On Nov 14, 2016, at 12:44 PM, Tony Parker  wrote:
>> 
>> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
>> Foundation is just one of the libraries involved? On Darwin, the prefs are 
>> organized by application, not by framework.
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Will Stanton via swift-corelibs-dev]

Hello Tony and Philippe,

I don’t think it would be odd for cookie/setting files to be in a folder named 
after Foundation (namely ~/.foundation):
- The files are owned by Swift/Linux Foundation in the sense Foundation writes 
them, and Foundation is the only one that should access them directly. 
Foundation should enforce security.
- On macOS, settings seem to be written to 
~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed 
~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
‘.foundation’ is used in lieu of a library directory, and I feel this is 
acceptable so as not to clash with any user ~/Preferences or ~/Library 
directory.  I am OK with the ‘Foundation ownership’ per above.
And, executable name seems reasonable in lieu of bundle ID.

I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist 
may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is 
probably necessary anyway and better (fewer search paths to loop through, 
possibly less I/O).


Am interested in alternatives of course :-)
- But having separate folders for each app seems complicated, ex. 
'~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
- I don’t really mind the name of an encapsulating folder, .foundation or 
otherwise.
- Placing system configuration files in /etc is a norm, but I think I’d feel 
more comfortable with Swift app settings in /home/user (easier to keep track 
of, and I can delete the whole thing without consequences*). I’m also not 
writing any real low-level services in Swift… but others probably are… but they 
probably have their own code to write config data to /etc!


To Philippe’s points about security+future-proofing:
Perhaps the cookie file could be named per version of its format:
~/.foundation/Cookies/shared initially
When we have a new format:
~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?

I also think it should be up to Swift Foundation to enforce cookie security on 
a per-app/family basis (the latter requires changes to the package structure?).
Perhaps for now, it is possible to save the hash and name of the executable 
storing a cookie? And Foundation can load cookie storage only if the executable 
name and file haven’t changed? (Is that an unnecessary pain?)

Regards,
Will Stanton

> On Nov 14, 2016, at 12:44 PM, Tony Parker  wrote:
> 
> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
> Foundation is just one of the libraries involved? On Darwin, the prefs are 
> organized by application, not by framework.

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Philippe Hausler via swift-corelibs-dev]

Furthermore isn’t it a bit of a conflict if we have multiple versions of 
Foundation running apps on a server? I would expect that the mutable state of 
cookies should never be shared across processes not just from a security 
standpoint but also from a versioning standpoint. 

Let have a scenario where there are two web apps running on the same server. 
They should never share data between them unless specifically allowed to. 
Service A uses Foundation version A and service B uses version B. Unless 
service A and B have privileges to communicate they should never use common 
storage for cookies or preferences. This could allow service A to 
inappropriately use the stored credentials of service B if they are stored in 
the same directory. Moreover if the version B of Foundation has some refinement 
to the storage version of the cookie the file may be incompatible with 
Foundation A’s reading schema. 

In my opinion the directories should be unique to the services running unless 
they share a system based privilege system that is a common version (e.g. they 
are allowed to talk to each other and are not sandboxed apart).

Of course some of this could be side-stepped by having the services running as 
different users. But the versioning issue still occurs and should perhaps be 
something that we consider.


> On Nov 14, 2016, at 9:44 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
> Foundation is just one of the libraries involved? On Darwin, the prefs are 
> organized by application, not by framework.
> 
> - Tony
> 
>> On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Thanks Will! 
>> 
>> "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
>> 
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> 
>> -Will Stanton mailto:willstant...@yahoo.com>> 
>> wrote: -
>> To: Pushkar N Kulkarni/India/IBM@IBMIN
>> From: Will Stanton mailto:willstant...@yahoo.com>>
>> Date: 11/08/2016 08:45AM
>> Cc: swift-corelibs-dev > >
>> Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
>> 
>> Was wondering if there could be a common directory for Foundation-related 
>> files, such as NSUserDefaults in addition to cookie storage?
>> 
>> So maybe for cookies:
>> NSHomeDirectory() + "/.foundation/Cookies/shared"
>> 
>> And settings for an app/service:
>> NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
>> 
>> 
>> And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond 
>> handles cookies… or caches things, but I think I agree with Kenny that 
>> naming symmetry would be nice if there is a per-user cookies file.
>> 
>> So having a /Library may be nicer, but potentially unnecessary?
>> NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
>> 
>> Regards,
>> Will Stanton
>> 
>> > On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev 
>> > mailto:swift-corelibs-dev@swift.org>> wrote:
>> > 
>> > Hi Pushkar,
>> > 
>> > Good question. If this were Darwin I guess I would say 
>> > ~/Library/Application Support — but I don’t know what the best practices 
>> > are on other platforms. Does anyone out there have some suggestions?
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
Foundation is just one of the libraries involved? On Darwin, the prefs are 
organized by application, not by framework.

- Tony

> On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev 
>  wrote:
> 
> Thanks Will! 
> 
> "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -Will Stanton mailto:willstant...@yahoo.com>> 
> wrote: -
> To: Pushkar N Kulkarni/India/IBM@IBMIN
> From: Will Stanton mailto:willstant...@yahoo.com>>
> Date: 11/08/2016 08:45AM
> Cc: swift-corelibs-dev  >
> Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
> 
> Was wondering if there could be a common directory for Foundation-related 
> files, such as NSUserDefaults in addition to cookie storage?
> 
> So maybe for cookies:
> NSHomeDirectory() + "/.foundation/Cookies/shared"
> 
> And settings for an app/service:
> NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
> 
> 
> And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond 
> handles cookies… or caches things, but I think I agree with Kenny that naming 
> symmetry would be nice if there is a per-user cookies file.
> 
> So having a /Library may be nicer, but potentially unnecessary?
> NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
> 
> Regards,
> Will Stanton
> 
> > On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev 
> > mailto:swift-corelibs-dev@swift.org>> wrote:
> > 
> > Hi Pushkar,
> > 
> > Good question. If this were Darwin I guess I would say 
> > ~/Library/Application Support — but I don’t know what the best practices 
> > are on other platforms. Does anyone out there have some suggestions?
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Some feedback / direction on an issue?

[Mark Woollard via swift-corelibs-dev]

Hi

I decided to see if I could contribute and started looking into what seemed it 
would be a straightforward issue in Foundation framework for Linux. After 
debugging this led me to conclude it seems to be a more fundamental issue, 
maybe with the compiler code generation, around exception handling wrt Linux. 
I’d be interested in some feedback / guidance on this - am happy to take 
ownership and see where I might get with it but have a lot of learning to do !

The initial issue I looked at was SR-1547 
 in Foundation but this I determined to 
be the same issue as SR-585 .

I’ve added some comments to these issues relating to my investigation. Anyone 
have any more insight into this issue or suggestions on where to look next ?

Thanks
Mark

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Pushkar N Kulkarni via swift-corelibs-dev]

Thanks Will! "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to mePushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-Will Stanton  wrote: -To: Pushkar N Kulkarni/India/IBM@IBMINFrom: Will Stanton Date: 11/08/2016 08:45AMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageWas wondering if there could be a common directory for Foundation-related files, such as NSUserDefaults in addition to cookie storage?So maybe for cookies:NSHomeDirectory() + "/.foundation/Cookies/shared"And settings for an app/service:NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond handles cookies… or caches things, but I think I agree with Kenny that naming symmetry would be nice if there is a per-user cookies file.So having a /Library may be nicer, but potentially unnecessary?NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"Regards,Will Stanton> On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev  wrote:> > Hi Pushkar,> > Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev