FTP to SFTP?

[kawajax]

Is there any change make FTP To SFTP?
I mean "Change File Permissions" should be via SFTP instead FTP.

[Arantor]

Not without a massive overhaul of the system. SFTP support is a huge thing to add and requires many more changes than just what seems obvious.

[live627]

SCP   

[kawajax]

SCP   

How SCP resolve "Change File Permissions" FTP issue?

[Arantor]

By fixing the underlying problem that is the entire package manager's behaviour in the first place.

[kawajax]

How to enable that SCP instead FTP in "Change File Permissions"?

[Arantor]

Please, don't get into things you don't understand.

SCP is file copying over a secure connection, and complements the SFTP setup rather than supplements it. But none of that matters a damn when the entire setup is about editing files which is fundamentally insecure, fundamentally broken and totally the wrong way to do it.

The correct thing is to nuke the package manager and start over rather than grafting on ever more levels of things to break.

[margarett]

There isn't such option. Only FTP is supported.

What was being discussed is a "maybe in the future for next versions" possibility

Edit: Ninja'd

[kawajax]

Please, don't get into things you don't understand.

I'm sorry for sarcasm of my comments.

There isn't such option. Only FTP is supported.

Yes, i know it.
That is reasons why i ask it, SFTP is more secure than FTP. And many ISP demand it, so FTP function not work in "Change File Permissions" case

btw. i'm data communications professional, so don't underestimate my knowledge.

[Arantor]

That's kind of my original point: SCP won't fix your problems. Neither really will SFTP.

[kawajax]

That's kind of my original point: SCP won't fix your problems. Neither really will SFTP.

My "problem" is that SMF only support FTP, and my ISP demand SFTP (like many ISP in my country). SCP is not valid any case, because SCP is only for transfer, not for handling files.

[Arantor]

And none of that solves your problem ANYWAY.

You can do what SMF does yourself through your file manager. All it's doing is escalating file permissions so Apache/PHP can write to the file. This is a terrible practice, it's known to be insecure (even if you put permissions back again after, not that most people do anyway) and the entire thing needs to be ripped out entirely.

[kawajax]

And none of that solves your problem ANYWAY.

You can do what SMF does yourself through your file manager. All it's doing is escalating file permissions so Apache/PHP can write to the file. This is a terrible practice, it's known to be insecure (even if you put permissions back again after, not that most people do anyway) and the entire thing needs to be ripped out entirely.

Why there is in SMF this kind of options:

[Arantor]

Because SMF's package manager is outdated and stupid.

[kawajax]

Because SMF's package manager is outdated and stupid.

Thanks for info.

[Kindred]

On the one hand, smf package manager has some potential issues...   On the other hand, what it does, allowing mods to edit code if fundamentally more configurable than any other system that I can think of...   Of course, it has the downside of being fundamentally more exploitable as well, if someone can get into the system...

As for FTP versus sftp, just set your file permissions correctly for file edits... Apply the mod... And then set them back to secure...  There will be no need for FTP or sftp.

[Arantor]

It's also so much more brittle as evidenced by the number of people that have parse issues with various mods. Fix the structure to not need edits and everyone lives a happier and more fruitful life out of it.

As for FTP vs SFTP all you're doing is what SMF would itself be doing, and that's still insecure too even if you secure it, unless the mod doesn't add any of its own files.

[Kindred]

Yup... Powerful but brittle, because  it does assume that mod authors know what they are doing...   Which is a poor assumption in many cases, I will grant you...

But wait.,,   How is it insecure if I go back through and set all my files to 444?

[Arantor]

Who owns the files? That's the key to it.

If you're letting apache2/nobody/www-data write files that are new files, THAT will be the file owner is way too many cases. At which point 444 is irrelevant because apache2/nobody/www-data can come along and chmod its own files.

This is why chown needs to be sorted out, which is why you pretty much need to enforce chownership at file creation which can't be done in normal PHP. Ironically it *can* be done in FTP but only if you upload via FTP rather than just fudging permissions.

[Kindred]

Ah. I understand now... Hmmmmm....

[Arantor]

If only someone hadn't already figured all this out, including writing a zip parsing library that didn't require dumping all the files to the file system but left them accessible as strings, so they could be passed to an upgraded FTP library for the purposes of uploading all of these things. I live in hope that such things will one day come to pass.

[Kindred]

Pbbbbbtttttttt....

[Arantor]

But it's an interesting point that none of this is theoretical, even in the wider SMF ecosystem.

It's pretty much only phpBB and SMF that primarily rely on file edits these days; phpBB finally caught up with where SMF was 10 years ago when it finally got around to including Automod. But everyone else left SMF behind; I find it *extremely* interesting to note that XenForo and IPB don't do raw edits, not even of the templates, which makes it significantly more reliable.

[Kindred]

But the. How do mods edit the core functionality?

Don't say hooks...   Because hooks are great, and should be used when possible... But sometimes changing the code is the only way to accomplish the modification.

[Arantor]

In XF's case, hooks and the fact you can do all kinds of neat class loading to extend behaviours easily. And their templates are in the DB, but there is a kind of soft find/replace done prior to template compilation, rather than a hard find/replace like SMF does.

In practice you don't generally *need* to touch the raw code and there are literally hundreds of plugins that don't require edits. Heck, the upgraded search backend - that integrates ElasticSearch - is an editless plugin, as is their resource manager (what they use for their mod site)

Of course, this assumes the application was built properly in the first place with extensibility in mind.

[Kindred]

Right... So possible for 3.0 with the complete rewrite in mind, but unlikely to happen in the existing 2.x infrastructure...

[Arantor]

I was having this discussion when smCore was still in gestation. The only person who ever gave me a credible argument against removing file edits was Unknown, and then it was all about providing bug fix packages, which is literally the only use case that *should* be file edit only but then you'd have a faster release cycle to deal with that kind of thing anyway

None of these issues are new. None of the solutions are new either. More importantly, neither is the general resistance to the idea of doing it anyway. That's just as strong as ever.

[margarett]

In this case I would also be very resistant because I, like Kindred and probably most others, don't really understand how can you get to PackMan's flexibility without file edits.

I have to say, this issue with the security attached to PackMan and theme editor is not something I'm too concerned... For all cases you need a broken admin account and, when that happens, all bets are off already...

Of course, if there's a safer way to do the same thing, it should be checked

[Kindred]

well, no, Bruno, What I believe Arantor just said is that -- if the mod uploads its own files, then they are uploaded with the owner being php...
which means a 444 chmod file is chwoned by the system, not the user and thus could actually still be modified by another php scipt.

[Arantor]

The sorts of trouble you can get into with packman and the theme editor CANNOT BE ACHIEVED in other forum systems. Did I mention already that what happened with Avast could not have happened in other forum systems, even if the admin account was compromised?

By forcing you to upload the files yourself, ownership is set to you not to the system. This is why in Wedge's plugin manager, 1) file edits are prevented and 2) the plugin manager actually performs uploads over FTP for you ensuring you get proper ownership.

As far as flexibility goes, it is not a regular complaint with XF mod authors. Template edits can be done safely with a find/replace that doesn't actually modify the template, and the vast bulk of classes can be overloaded with what even amounts to a subtle form of mixin which means extending virtually any behaviour is not difficult. There are a few specific exceptions but these are limited only to places where classes are manually instantiated rather than through the various proper load behaviours.

I can't speak for IPB with too much depth; the only IPB stuff I've installed are the official add-ons but they all follow the same pattern: upload the files manually, run stuff to activate them. But the parts of their ACP dedicated to add-ons all talk about hooks and registering plugins that are pre-existing files.

[Kindred]

So -- in general I disagree with the FIRST part of what was done on wedge...   I think that file edits are a key point in flexibility of modding (and yes, we've already been over the issue with modders' code in general)

the second part is what would make it more secure though -- using FTP the correct way - and IMO, that is where the current PakMan is lacking.

not sure about that description of XF... I'd have to look into it more.

[Arantor]

WHY are they a key point in flexibility? Because the current code is so labyrinthine that you don't have any choice but to do so.

SimpleDesk was almost totally converted to hooks for Wedge, the only sticking point was the attachments system which was entirely a kludge effort in the first place to limit support issues. Had I taken the better travelled path, that would also be a non issue. Or if the attachments system were not so explicitly tied to topics and allowed access from other subsystems cleanly.

You're also missing a great amount of the other benefits of decoupling edits. How many times have you dealt with users that have broken forums or partially broken forums because of bad edits? If you have a design that allows for extending the system without edits, not only does that problem basically go away, but you get improved ruggedness out of it. Bad plugin? Rename the folder and it won't be loaded. Heck even WP is better about this than SMF is and much as I hate to defend the monstrosity of WP, that's basically how they do it too... not hacking up core code.

There is a reason phpBB and SMF are the only major platforms still doing this, while everyone else has moved onto more elegant, more stable and more refined methods of doing this stuff.

[margarett]

And this comes in line to what I pointed above: most of us have no idea how can the same or similar mod flexibility be achieved without file edits

And another problem is that PackMan is 10+ years old. And it was great when I first started in SMF, not having to perform file edits by hand! Still is So now it is what it is... But this discussion is great for future version

[Arantor]

And to be honest, I can't be bothered to explain all the mechanics of how it should work because I feel like I'd be wasting my time, because there is no way I will be around for SMF 3.0. I'll need something before 2020.

[Kindred]

pessimist...   we can get it done by 2019

[Arantor]

And then you remember that XenForo got to their first public release in a year from scratch - with two developers.

[Kindred]

yes...   I know.   and I have said this before --   creating a software from the start is actually EASIER than updating versions and having to support existing version(s) and community

If we had 2 developers working full time on SMF 3.0 and not doing anything else (like providing support or fielding security questions on the existing platform), I'd bet we could have a release by the end of next year, fairly easily.   If we could afford to pay developers, we might do as well... but without switching to a paid model (which SMF will never do) we can't compete on that sort of timeline.

We can, however, build and support a good, free product

[Arantor]

And why do you think I'm advocating 3.0 as a from scratch build? Building 3.0 using 2.x as a basis is insane at this point.

Also note that Kier and Mike don't generally field questions themselves, that's what the rest of the moderator team and community do. That's because they know how to work together and communicate with each other and raise things that are possible dev concerns to the devs without the devs having to basically figure it out for themselves as has historically been the case here.

[Kindred]

Arantor....  you seem to be under the impression that you are arguing something here?

It has been our intention to scratch build 3.0 for 2 years now...

Actually, our support team is usually pretty good these days about answering or flagging things for more knowledgeable folks. Although that has not historically been the case, the current team is good about it and you are one of the devs who felt the need to answer almost every support topic is you   
I appreciate your passion, but you tend to try to do everything when you get into something.
Not necessarily a bad trait, but it can lead to burnout.

[Arantor]

Yes, I'm arguing a point that you still don't seem to be getting

Two guys built XF from scratch in a year. Quite a few more people haven't been able to get from 2.0 to 2.1 (which is a smaller job) in *three* years. Call me skeptical but I don't see that group of people being able to get a from scratch thing built any time this side of 2020, knowing as I do how this group operates. 2.0 wasn't a from scratch thing and that took 5 years. And there's still a lot of strange oddities left behind even now because of 1.1's structure.

Of course I tried to answer every support topic. How else would I know what the weaknesses of the software are when even the support team could not tell me what the common support issues were when I asked?

How else would I know what the limitations of the package manager were if I'd never made packages? How else would I know what's illogical about the admin panel if I hadn't tried to explain it to other people? Rubber duck debugging works for many things, including illogical UI.

I'd have been more willing to let the team contribute if I felt I could trust them. But we all know by now that I'm a terrible person anyway, so there's that too.

[Kindred]

nah, you're not a terrible person, you just try to do everything. You need to allow others to step up.
(after all - why should anyone put in more effort, when you are already trying to do/doing everything yourself, lol)


you're arguing a point which I say is completely and utterly wrong in this one regard. I've understood your point months ago... I just happen to disagree completely with the position.

[Arantor]

Did you read the link? It's worth the read.

I kept putting in the effort *because* others weren't. Then others realised they didn't have to so things went around in a circle.

[Kindred]

well, yes and no...

The team was having some personnel issues a while back..  We got a good set though - in everything but the dev section.
When you and Suki stepped up the dev team, we were solid...   and I had hoped that you two could focus on dev.


and yes, I read the link...   

The fact is - we are on our way again, after a (not-so) brief intermissions while we rebuilt the qualified devs.
The current people working are pretty well. I'd love to see you join them - but I'm not pushing (and not holding my breath, lol) and will just appreciate the fact that you're still around the community and can still point people the right way even if you're not dropping code into the repository yourself.

[Arantor]

I will be honest, when Dragooon joined the team, I felt a huge wave of relief. Because he's better than I am and a better fit for this project than I ever was or will be.