Publish API used by luasec v2 #346
Conversation
Remove CFLAGS optimization overrides, add -Wl,-soname option to LDFLAGS for external linking.
|
rebased and force pushed to restart CI |
|
Hi there. In my point of view (as Linux package maintainer) this needed to unbundle luasocket from luasec package for packaging reasons (see https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies, https://fedoraproject.org/wiki/Bundled_Libraries, https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles for rationales). Still there other advantages/enhancements:
|
|
Wow, a mention on a PR reworking another PR I made 8.5 years ago. So, uh, I have no clue really. By the mention of Fedora in #72, I guess that this was related to the ABI issues observed on Fedora systems, which had something to do with LuaSec having to duplicate some of the code from LuaSocket (structs, in particular). I don't recall all the specifics, unfortunately. I also have stopped using Fedora in the meantime, so I wouldn't know if this is still an issue over there. It is unclear to me what the LuaSec maintainer has been trying to tell me (~8 years ago) in the other PR: lunarmodules/luasec#5 (comment). It seems to indicate that the linking issues have been resolved in later versions of either library, but I cannot confirm this. I see that brunoos has already been pinged in this thread, so I'll leave it up to them. |
|
Hi, I think that keep one base for the code is a good thing for luasec too, but the self contained version like it is today seems easier to build packages. How does the build process will be performed for example with luarocks? |
|
I have no idea how to make static linking work for the vcpkg port without this. |
Static linking cannot work on any platform due to the conflict with luasocket. There is a PR against luasocket that would resolve the situation but it has not been merged in a number of years: lunarmodules/luasocket#346
|
Not sure it makes sense (since I don't know either codebase very well), but could integrating the 2 code bases also solve the issues? The need to secure connection keeps ever increasing. So by default building both packages from the same repo, and optionally disabling the luasec build using a flag. But as mentioned I'm not knowledgable, so might be a very silly idea... |
|
Yes integration would solve this issue. |
Static linking cannot work on any platform due to the conflict with luasocket. There is a PR against luasocket that would resolve the situation but it has not been merged in a number of years: lunarmodules/luasocket#346 Also change the upstream repo to lunarmodules since it was moved.
Static linking cannot work on any platform due to the conflict with luasocket. There is a PR against luasocket that would resolve the situation but it has not been merged in a number of years: lunarmodules/luasocket#346 Also change the upstream repo to lunarmodules since it was moved.
Static linking cannot work on any platform due to the conflict with luasocket. There is a PR against luasocket that would resolve the situation but it has not been merged in a number of years: lunarmodules/luasocket#346 Also change the upstream repo to lunarmodules since it was moved.
|
@catwell what decision was made? Why PR was closed? |
|
@catwell -- sorry meant for @winterheart I for one wouldn't put socket and sec responsibility on Lua, The listener I would use is Maybe luasec can handle the crypto from a fd that way? |
|
@winterheart I guess https://smarden.org/runit/ |
|
@georgalis that doesn't sound particularly related to this PR? |
@TheCycoONE let me clarify. This issue/pr has been closed with won't fix. At least that is a simple assumption on my part (and kinda obvious). The reason probably has to do with the complexity of integrating a PR that references another PR that is 10.5 years old and by an author no longer working on their project. The repositories have changed, and the problem is relating to simultaneous network support, on multiple OS, with shared libraries, compilers, and dynamic library includes. Difficult. The network, cryptography, and OS libraries have all been changing. I mean, if you want a module with an API for a lua program to process encrypted internet connections, consider instead gluing runit, socklog, and openssl together to spawn your lua program, because that's doable, and I don't see anyone not saying wontfix to this issue. Maybe there is hope for a luasec module API to do it all? (Safe threads anyone?) I for one would love it. But, if you want another reason, I think you need new developers in the new repository with a new PR, to move this forward. Won't fix is related, right? |
|
Hmm, sorry for the confusion here, I don't remember closing this PR and I definitely would not have closed it without an explanation. So my best guess is I closed it by mistake! I either confused it with another PR in another repository, or I misclicked something in the Github UI. Reopening it now, sorry again! |
|
I do remember looking at that PR and thinking that indeed I have been thinking for a while that merging LuaSec and LuaSocket could be a good idea. |
@catwell it would certainly be convenient! Are there any other cases where socket management and crypto are bundled for easy use? If doc and/or build/run tests confirmed which OS and versions are supported that would be great. I know the network stack is very different between Linux, Win, and Darwin. Lua users would anticipate modules work on their OS and try it on their platforms. Would this be for dev with expectation to switch to nginx, iis, or apache for scaling? If so, how would that transition work? If not, would you publish end-of-support dates for the given versions, for prod users to consider? I guess the problems with static vs dynamic linking for vendor packaging has already been mentioned. Might also state in the doc the motivations vs lua as a module or cgi in a battle tested web server, so users do not make incorrect assumptions. Lots of software breaks with Darwin major updates, which are frequent, so that might be something else to consider. Same questions for threading. Whether it's managing multiple network connections, a crypto layer, or application integration; all that as a module to ground application development into a standard platform would create a lot of interest, a better LAMP! But another question is security. Presumably, openssl and other dependencies will be used? How will versions and branches be coordinated for release? What will be required for patching or roll back? Combining tools that each do one thing well is my preference. When tasks like this require a lot of tools, I tend to script their deployment to avoid mistakes and manual effort. When there are many moving parts, separating them into atomic components makes the most sense, at least that's what I do when analyzing a broken stack. |
|
Oooh, luasocket is a client! In that case roll in crypto and protocol handshakes too! maybe rename it luaclient though? |
Seems this is best approach. I would be glad to see LuaSec merged into LuaSocket codebase. |
Reworked and rebased changes from #72.
Closes #72, #80.