Thread overview
Released vibe-core 1.0.0 and vibe.d 0.8.0
Jul 15
tetyys
July 10
After a long journey - it took over eight months - the new core package is finally ready. Along with it, version 0.8.0 of vibe.d is released. This marks a major milestone in vibe.d's development.

Apart from offering support for using the new core package, 0.8.0 now also employs @safe and nothrow where possible, making it possible to write fully @safe vibe.d applications. And of course, as always, there is also a long list of other improvements and bug fixes.

The core package can be considered as a complete rewrite of the original vibe-d:core package, retaining a mostly backwards compatible API from a library user's point of view. Lots of changes went into modernizing the code and removing inherent performance limits of the previous design*.

See the dedicated blog post for a basic explanation of the changes:
https://vibed.org/blog/posts/introducing-vibe-core

The change log for vibe.d 0.8.0 is listed here:
https://vibed.org/blog/posts/vibe-release-0.8.0

Finally, to make use of the vibe-core module, which is highly recommended outside of critical production systems, you'll have to manually enable it in the package recipe of your project:

- dub.sdl:
    dependency "vibe-d:core" version="~>0.8.0"
    subConfiguration "vibe-d:core" "vibe-core"

- dub.json:
    {
        ...
        "dependencies" : {
            ...
            "vibe-d:core": "~>0.8.0"
        },
        "subConfigurations": {
            ...
            "vibe-d:core": "vibe-core"
        }
    }

DUB packages:
https://code.dlang.org/packages/vibe-d/0.8.0
https://code.dlang.org/packages/vibe-core/1.0.0

* Note that no dedicated performance tuning has been done yet, so performance levels are expected to still be on a similar level.


BTW, @CyberShadow, I originally sent this using a NG client, but the thread never appeared on forum.dlang.org
July 10
On 7/10/17 8:11 AM, Sönke Ludwig wrote:

> BTW, @CyberShadow, I originally sent this using a NG client, but the thread never appeared on forum.dlang.org

Even this one isn't there... Should be here: http://forum.dlang.org/post/mmfrsonxrfxwltkfvliw@forum.dlang.org

-Steve
July 10
Am 10.07.2017 um 15:24 schrieb Steven Schveighoffer:
> On 7/10/17 8:11 AM, Sönke Ludwig wrote:
> 
>> BTW, @CyberShadow, I originally sent this using a NG client, but the thread never appeared on forum.dlang.org
> 
> Even this one isn't there... Should be here: http://forum.dlang.org/post/mmfrsonxrfxwltkfvliw@forum.dlang.org
> 
> -Steve

Opened a ticket: https://github.com/CyberShadow/DFeed/issues/87
July 11
Note: Due to recent issues with OpenSSL, the way OpenSSL/Botan get selected as the TLS provider has changed. If you are using Botan, you'll have to explicitly select the "botan" configuration of the new "vibe-d:tls" package:

	dependency "vibe-d:tls" version="~>0.8.0"
	subConfiguration "vibe-d:tls" "botan"

or for dub.json:

	"dependencies": {
		...
		"vibe-d:tls": "~>0.8.0"
	},
	"subConfigurations": {
		...
		"vibe-d:tls": "botan"
	}
July 11
Many thanks!

https requests with manual memory management leads to assertion.

DMD64 D Compiler v2.074.1
DUB version 1.3.0
Linux x86_64

Test case:

/+ dub.json:
	{
		"name": "test",
		"versions": ["VibeManualMemoryManagement"],
		"dependencies": {
			"vibe-d": "~>0.8.0"
		}
	}
+/

module main;

import std.conv;
import std.stdio;
import vibe.core.core;
import vibe.http.client;

void main() {
	runTask({
		HTTPStatus status;
		requestHTTP("https://steamcommunity.com", (scope request) {}, (scope response) {
			status = response.statusCode.to!HTTPStatus;
			response.dropBody();
		});
		writefln("status: %s", status);
		exitEventLoop();
	});
	runApplication();
}

Result:

CoreTaskFiber was terminated unexpectedly: Assertion failure
Program exited with code 255

July 11
slightly reduced

/+ dub.json:
	{
		"name": "test",
		"versions": ["VibeManualMemoryManagement"],
		"dependencies": {
			"vibe-d": "~>0.8.0"
		}
	}
+/

module main;

import std.conv;
import std.stdio;
import vibe.http.client;

void main() {
	HTTPStatus status;
	requestHTTP("https://steamcommunity.com", (scope request) {}, (scope response) {
		status = response.statusCode.to!HTTPStatus;
		response.dropBody();
	});
	writefln("status: %s", status);
}
July 11
Am 11.07.2017 um 15:13 schrieb Jack Applegame:
> slightly reduced
> 
> /+ dub.json:
>      {
>          "name": "test",
>          "versions": ["VibeManualMemoryManagement"],
>          "dependencies": {
>              "vibe-d": "~>0.8.0"
>          }
>      }
> +/
> 
> module main;
> 
> import std.conv;
> import std.stdio;
> import vibe.http.client;
> 
> void main() {
>      HTTPStatus status;
>      requestHTTP("https://steamcommunity.com", (scope request) {}, (scope response) {
>          status = response.statusCode.to!HTTPStatus;
>          response.dropBody();
>      });
>      writefln("status: %s", status);
> }

Thanks! I've pushed a fix for 0.8.1: https://github.com/rejectedsoftware/vibe.d/commit/c0a5050088d41b726984e3beb71b9a976aaf2ba8
July 15
very nice!

one question about the </ encoding: https://github.com/rejectedsoftware/vibe.d/commit/e4a600f911218c49f9984734b8ba36f193e99c17

wouldn't this https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Image_XSS_using_the_JavaScript_directive pass normally?
July 16
Am 15.07.2017 um 23:54 schrieb tetyys:
> very nice!
>
> one question about the </ encoding:
> https://github.com/rejectedsoftware/vibe.d/commit/e4a600f911218c49f9984734b8ba36f193e99c17
>
>
> wouldn't this
> https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Image_XSS_using_the_JavaScript_directive
> pass normally?

If a user supplied image URL is passed to the "src" attribute unchecked, then yes. But this would work regardless of the JSON escape rules and really needs to be prevented by the application code.

However, I just noticed that this is still possible to exploit in the Markdown processor. User defined HTML is filtered, but link targets are passed to the rendered HTML as-is (just HTML encoded).
July 16
Am 16.07.2017 um 11:17 schrieb Sönke Ludwig:
> (...)
>
> However, I just noticed that this is still possible to exploit in the
> Markdown processor. User defined HTML is filtered, but link targets are
> passed to the rendered HTML as-is (just HTML encoded).

https://github.com/rejectedsoftware/vibe.d/pull/1846