Re: [DISCUSS] Scope of 1.5.0 release

[Mike Jumper]

I'll move forward with creating the "staging/1.5.0" branches and
updating the bases of any relevant PRs.

- Mike

On Tue, Mar 8, 2022 at 3:04 PM Mike Jumper  wrote:
>
> That sounds doable to me.
>
> - Mike
>
> On Tue, Mar 8, 2022 at 12:44 PM Nick Couchman  wrote:
>>
>> All items in the scope look good to me, including the close-to-ready at the
>> end. Maybe we can make end of March for a 1.5.0 release?
>>
>> -Nick
>>
>> On Tue, Mar 8, 2022 at 2:12 PM Mike Jumper  wrote:
>>
>> > Hello all,
>> >
>> > Thoughts on scope and getting the release process going for 1.5.0? There's
>> > a good number of changes completed since 1.4.0 went out:
>> >
>> >- GUACAMOLE-745: Add support for OpenSSH private key format
>> >- GUACAMOLE-746: Add support for ED25519 SSH keys
>> >- GUACAMOLE-876: RDP "reconnect" resizing breaks RDPDR
>> >- GUACAMOLE-896: web browser could not play large size of session
>> >recording file as 1G size.
>> >- GUACAMOLE-1275: issue caused while logging in to user with all
>> >permission inherited from parent user group and only connection
>> > permission.
>> >- GUACAMOLE-1330: guacenc build fails against FFmpeg 4.4
>> >- GUACAMOLE-1394: Support setting "openid-groups-claim-type" property
>> >via Docker environment variable
>> >- GUACAMOLE-1406: Documentation inconsistency regarding Docker setup
>> >(environment)
>> >- GUACAMOLE-1418: Add support of SQL Server JDBC plugin in Docker Image
>> >- GUACAMOLE-1433: Docker implementation, The authentication type 10 is
>> >not supported.
>> >- GUACAMOLE-1435: FreeRDP DVCPluginEntry returns UINT for all 2.0
>> >versions
>> >- GUACAMOLE-1446: Some typo mistakes in some source files
>> >- GUACAMOLE-1453: SSL communication by mariadb connector/J is not
>> >possible
>> >- GUACAMOLE-1475: Make api-session-timeout adaptable in Docker
>> >- GUACAMOLE-1491: Fix environment name of GUACD_PORT
>> >- GUACAMOLE-1508: Allow bundling of library .jar files within extensions
>> >- GUACAMOLE-1509: Provide better CSS/structural context for branding and
>> >theming extensions
>> >- GUACAMOLE-1511: Automatically trim trailing whitespace from
>> >guacamole.properties values
>> >- GUACAMOLE-1523: Cannot copy/paste into admin fields if local clipboard
>> >integration is unavailable
>> >- GUACAMOLE-1539: "FATAL: No authentication configured" when using the
>> >auth-json extension
>> >- GUACAMOLE-1543: Shared recording functionality should be public
>> >- GUACAMOLE-1545: SessionRecording "onload" event fires twice
>> >
>> > In addition to the above, the following are open with at least some portion
>> > merged:
>> >
>> >- GUACAMOLE-641: Support storage of sensitive data within key vaults
>> >- GUACAMOLE-957: Add support for querying multiple LDAP servers
>> >- GUACAMOLE-1293: Alert users when admins connect to their session
>> >- GUACAMOLE-1481: Migrate remaining events to new event API
>> >- GUACAMOLE-1507: Enable configuration of of the 'extension-priority'
>> >parameter via environment variable
>> >
>> > I'd also like to propose including the following within scope, as they look
>> > real close to merge:
>> >
>> >- GUACAMOLE-462: See recordings by clicking on history record
>> >- GUACAMOLE-1005: Docker: Allow configuring Tomcat's RemoteIPValve
>> >
>> >
>> > - Mike
>> >

Re: [DISCUSS] Scope of 1.5.0 release

[Mike Jumper]

That sounds doable to me.

- Mike

On Tue, Mar 8, 2022 at 12:44 PM Nick Couchman  wrote:

> All items in the scope look good to me, including the close-to-ready at the
> end. Maybe we can make end of March for a 1.5.0 release?
>
> -Nick
>
> On Tue, Mar 8, 2022 at 2:12 PM Mike Jumper  wrote:
>
> > Hello all,
> >
> > Thoughts on scope and getting the release process going for 1.5.0?
> There's
> > a good number of changes completed since 1.4.0 went out:
> >
> >- GUACAMOLE-745: Add support for OpenSSH private key format
> >- GUACAMOLE-746: Add support for ED25519 SSH keys
> >- GUACAMOLE-876: RDP "reconnect" resizing breaks RDPDR
> >- GUACAMOLE-896: web browser could not play large size of session
> >recording file as 1G size.
> >- GUACAMOLE-1275: issue caused while logging in to user with all
> >permission inherited from parent user group and only connection
> > permission.
> >- GUACAMOLE-1330: guacenc build fails against FFmpeg 4.4
> >- GUACAMOLE-1394: Support setting "openid-groups-claim-type" property
> >via Docker environment variable
> >- GUACAMOLE-1406: Documentation inconsistency regarding Docker setup
> >(environment)
> >- GUACAMOLE-1418: Add support of SQL Server JDBC plugin in Docker
> Image
> >- GUACAMOLE-1433: Docker implementation, The authentication type 10 is
> >not supported.
> >- GUACAMOLE-1435: FreeRDP DVCPluginEntry returns UINT for all 2.0
> >versions
> >- GUACAMOLE-1446: Some typo mistakes in some source files
> >- GUACAMOLE-1453: SSL communication by mariadb connector/J is not
> >possible
> >- GUACAMOLE-1475: Make api-session-timeout adaptable in Docker
> >- GUACAMOLE-1491: Fix environment name of GUACD_PORT
> >- GUACAMOLE-1508: Allow bundling of library .jar files within
> extensions
> >- GUACAMOLE-1509: Provide better CSS/structural context for branding
> and
> >theming extensions
> >- GUACAMOLE-1511: Automatically trim trailing whitespace from
> >guacamole.properties values
> >- GUACAMOLE-1523: Cannot copy/paste into admin fields if local
> clipboard
> >integration is unavailable
> >- GUACAMOLE-1539: "FATAL: No authentication configured" when using the
> >auth-json extension
> >- GUACAMOLE-1543: Shared recording functionality should be public
> >- GUACAMOLE-1545: SessionRecording "onload" event fires twice
> >
> > In addition to the above, the following are open with at least some
> portion
> > merged:
> >
> >- GUACAMOLE-641: Support storage of sensitive data within key vaults
> >- GUACAMOLE-957: Add support for querying multiple LDAP servers
> >- GUACAMOLE-1293: Alert users when admins connect to their session
> >- GUACAMOLE-1481: Migrate remaining events to new event API
> >- GUACAMOLE-1507: Enable configuration of of the 'extension-priority'
> >parameter via environment variable
> >
> > I'd also like to propose including the following within scope, as they
> look
> > real close to merge:
> >
> >- GUACAMOLE-462: See recordings by clicking on history record
> >- GUACAMOLE-1005: Docker: Allow configuring Tomcat's RemoteIPValve
> >
> >
> > - Mike
> >
>

[DISCUSS] Scope of 1.5.0 release

[Mike Jumper]

Hello all,

Thoughts on scope and getting the release process going for 1.5.0? There's
a good number of changes completed since 1.4.0 went out:

   - GUACAMOLE-745: Add support for OpenSSH private key format
   - GUACAMOLE-746: Add support for ED25519 SSH keys
   - GUACAMOLE-876: RDP "reconnect" resizing breaks RDPDR
   - GUACAMOLE-896: web browser could not play large size of session
   recording file as 1G size.
   - GUACAMOLE-1275: issue caused while logging in to user with all
   permission inherited from parent user group and only connection permission.
   - GUACAMOLE-1330: guacenc build fails against FFmpeg 4.4
   - GUACAMOLE-1394: Support setting "openid-groups-claim-type" property
   via Docker environment variable
   - GUACAMOLE-1406: Documentation inconsistency regarding Docker setup
   (environment)
   - GUACAMOLE-1418: Add support of SQL Server JDBC plugin in Docker Image
   - GUACAMOLE-1433: Docker implementation, The authentication type 10 is
   not supported.
   - GUACAMOLE-1435: FreeRDP DVCPluginEntry returns UINT for all 2.0
   versions
   - GUACAMOLE-1446: Some typo mistakes in some source files
   - GUACAMOLE-1453: SSL communication by mariadb connector/J is not
   possible
   - GUACAMOLE-1475: Make api-session-timeout adaptable in Docker
   - GUACAMOLE-1491: Fix environment name of GUACD_PORT
   - GUACAMOLE-1508: Allow bundling of library .jar files within extensions
   - GUACAMOLE-1509: Provide better CSS/structural context for branding and
   theming extensions
   - GUACAMOLE-1511: Automatically trim trailing whitespace from
   guacamole.properties values
   - GUACAMOLE-1523: Cannot copy/paste into admin fields if local clipboard
   integration is unavailable
   - GUACAMOLE-1539: "FATAL: No authentication configured" when using the
   auth-json extension
   - GUACAMOLE-1543: Shared recording functionality should be public
   - GUACAMOLE-1545: SessionRecording "onload" event fires twice

In addition to the above, the following are open with at least some portion
merged:

   - GUACAMOLE-641: Support storage of sensitive data within key vaults
   - GUACAMOLE-957: Add support for querying multiple LDAP servers
   - GUACAMOLE-1293: Alert users when admins connect to their session
   - GUACAMOLE-1481: Migrate remaining events to new event API
   - GUACAMOLE-1507: Enable configuration of of the 'extension-priority'
   parameter via environment variable

I'd also like to propose including the following within scope, as they look
real close to merge:

   - GUACAMOLE-462: See recordings by clicking on history record
   - GUACAMOLE-1005: Docker: Allow configuring Tomcat's RemoteIPValve


- Mike

Re: [DISCUSS] Create builds@ list

[Mike Jumper]

On Mon, Feb 21, 2022 at 6:50 PM Mike Jumper  wrote:
>
> Hello all,
>
> Any objection to creating and migrating to a builds@ list for all these 
> Jenkins alerts?
>
> They're relevant to the committers, for sure, but I think they produce too 
> much noise for anyone who's on the list because they are interested in 
> dev-related topics.
>

OK - should be all set! The builds@ list has been created, and all of
our Jenkins jobs have been reconfigured to send alerts to that list
instead of dev@.

- Mike

Re: Jenkins build is back to normal : Guacamole » guacamole-server-master-fedora » 33,ubuntu #600

[Mike Jumper]

Please do not email the entire dev@ list with requests to be removed. You
are actually emailing all subscribers.

All you need to do is email dev-unsubscribe@ (using the email account you
subscribed with) and then follow the instructions in the confirmation email.

If you tried the above and it's not working, email me directly and I'll
take a look.

- Mike

On Fri, Feb 18, 2022, 06:55 Ignacio Valdes  wrote:

> Can I be removed/unsubscribed?
>
> On Thu, Feb 17, 2022 at 11:00 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-server-master-fedora/FEDORA_RELEASE=33,JENKINS_LABEL_EXPRESSION=ubuntu/600/display/redirect?page=changes
> > >
> >
> >
>

Re: It is a efficient implementation about tunnel in guacamole common project that uses nio

[Mike Jumper]

Can you provide any specific benchmarks/metrics showing that there is an
appreciable amount of CPU time being spent in thread context switches prior
to the proposed change, and a corresponding improvement after the change is
in place (for the same load)?

- Mike


On Tue, Feb 15, 2022, 22:44 Kurt.Ding  wrote:

> Hi Nick
>
> I'm glad to hear from you. Let me answer your questions and then we
> could have a discuss.
>
> Firstly let's assume one user  create hundreds remote connection, then
> in the linux server  which is deployed websocket  container the java
> process creates  hundreds of thread , it cause high cpu usage .
>
> In our production  server(8 core 16g)  ,  we meet  the case dozens of
> users create about 100 remote connections, unfortunately every user
> can't use vnc/ssh smoothly . Then we fix this problem with upgrade our
> server spec
>
> Secondly, as we all knows , many threads running in one server results
> in  thread context switch , and wouldn't increase the number of request
> per second.
>
> I hope this will make sense for you. And Your suggestion about use
> existing classes is a good idea. I will follow your idea and have a try.
>
> I am looking forward to have a discuss with you.
>
> Thanks Kurt
>
> 在 2022/2/15 22:23, Nick Couchman 写道:
> > On Tue, Feb 15, 2022 at 2:11 AM Kurt.Ding 
> > wrote:
> >
> >> Hi Guacamole Team
> >>
> >> Was I wrong about this  thread running model? Look forward to your
> reply.
> >>
> >>
> > This is a bit outside my area of expertise, but I guess I'd start by
> asking
> > the following questions:
> > * What actual problem are you trying to solve? What problem is thread
> > creation causing for you? Why is it that you want to limit or reduce the
> > number of threads created? Is reducing the number of threads actually
> going
> > to resolve whatever problem you're concerned about, or is it just going
> to
> > move the problem to another place?
> > * Rather than creating a WebSocket bridge, would it make more sense to
> > integrate your changes into one of the existing classes, perhaps either
> > extending an existing GuacamoleTunnel implementation or just
> implementing a
> > new GuacamoleTunnel that could then be used within the code? That would
> > seem to avoid this extra step of having to tunnel your WebSocket
> > connections through another server/class.
> >
> > -Nick
> >
>

[RESULT] [VOTE] Release guacamole-client POM artifact from 1.4.0 build

[Mike Jumper]

On Wed, Jan 5, 2022 at 1:22 PM Mike Jumper  wrote:
>
> Hello all,
>
> The guacamole-client build leverages a parent project for
> guacamole-common, etc. as of 1.4.0, however the parent pom.xml was not
> uploaded to Maven Central. As a result, any downstream usage of the
> 1.4.0 versions of the various libraries within guacamole-client will
> fail to build.
>
> As it was not explicitly included in the 1.4.0 release VOTE, and this
> will be the first time we release the parent pom as a build artifact,
> having a quick VOTE to recheck and explicitly decide whether to do so
> seems prudent.
>
> The missing Maven artifact containing the guacamole-client 1.4.0
> pom.xml has been uploaded to the following staging repository:
>
> https://repository.apache.org/content/repositories/orgapacheguacamole-1014/
>
> There are no source tags, dist uploads, etc. to check for the above.
> This is simply an upload of the pom.xml from the guacamole-client
> 1.4.0 source as already tagged and released.
>
> Please review and vote:
>
> [ ] +1 Approve uploading the guacamole-client 1.4.0 pom.xml as part of
> the existing 1.4.0 release
> [ ] -1 Don't approve uploading the pom.xml as described (please
> provide specific comments)
>
> This vote will be open for at least 72 hours.
>

The VOTE to upload the missing guacamole-client 1.4.0 pom.xml artifact
to Maven Central now closed. With a total of +3 binding votes from the
PMC, +1 from the community, and NO -1 votes, the VOTE passes. Overall
vote breakdown is as follows:

+1 Michael Jumper (binding)
+1 Carl Harris (binding)
+1 Nick Couchman (binding)
+1 Michele Sonnessa

Thanks to everyone who voted. I'll move forward with pushing the
relevant artifact.

- Mike

[SECURITY] CVE-2021-41767: Apache Guacamole: Private tunnel identifier may be included in the non-private details of active connections

[Mike Jumper]

Severity: moderate

Description:

Apache Guacamole 1.3.0 and older may incorrectly include a private
tunnel identifier in the non-private details of some REST responses.
This may allow an authenticated user who already has permission to
access a particular connection to read from or interact with another
user's active use of that same connection.

Credit:

We would like to thank Damian Velardo (Australia and New Zealand
Banking Group) for reporting this issue.

[SECURITY] CVE-2021-43999: Apache Guacamole: Improper validation of SAML responses

[Mike Jumper]

Severity: high

Description:

Apache Guacamole 1.2.0 and 1.3.0 do not properly validate responses
received from a SAML identity provider. If SAML support is enabled,
this may allow a malicious user to assume the identity of another
Guacamole user.

Credit:

We would like to thank Finn Steglich (ETAS) for reporting this issue.

[VOTE] Release guacamole-client POM artifact from 1.4.0 build

[Mike Jumper]

Hello all,

The guacamole-client build leverages a parent project for
guacamole-common, etc. as of 1.4.0, however the parent pom.xml was not
uploaded to Maven Central. As a result, any downstream usage of the
1.4.0 versions of the various libraries within guacamole-client will
fail to build.

As it was not explicitly included in the 1.4.0 release VOTE, and this
will be the first time we release the parent pom as a build artifact,
having a quick VOTE to recheck and explicitly decide whether to do so
seems prudent.

The missing Maven artifact containing the guacamole-client 1.4.0
pom.xml has been uploaded to the following staging repository:

https://repository.apache.org/content/repositories/orgapacheguacamole-1014/

There are no source tags, dist uploads, etc. to check for the above.
This is simply an upload of the pom.xml from the guacamole-client
1.4.0 source as already tagged and released.

Please review and vote:

[ ] +1 Approve uploading the guacamole-client 1.4.0 pom.xml as part of
the existing 1.4.0 release
[ ] -1 Don't approve uploading the pom.xml as described (please
provide specific comments)

This vote will be open for at least 72 hours.

Here is my +1.

Thanks,

- Mike

Re: Maven repository 1.4 missing parent

[Mike Jumper]

On Wed, Jan 5, 2022 at 8:32 AM Nick Couchman  wrote:
>
> On Wed, Jan 5, 2022 at 10:06 AM Michele Sonnessa  wrote:
>
> > Dear all,
> >
> > I’m trying to build and extension using brand new 1.4 api.
> > Unfortunately maven compilation fails because recent library versions
> > depend on a parent pom
> > which is not generally available on maven central repository.
> >
> >
> I see the artifacts present on the central repository:
>
> https://mvnrepository.com/artifact/org.apache.guacamole/guacamole-common/1.4.0
> https://mvnrepository.com/artifact/org.apache.guacamole/guacamole-common-js/1.4.0
> https://mvnrepository.com/artifact/org.apache.guacamole/guacamole-ext/1.4.0
>
> Not sure what is missing in your environment, but the officially published
> ones for the new version of Guacamole appear to all be present. It's
> possible that certain mirrors or repositories may take longer to update, so
> you might just check back, or make sure you're using the official versions
> noted above.
>

I'm seeing this issue as well. With the guacamole-client source having
been restructured to leverage a parent artifact to control
dependencies, things like guacamole-common depend on that parent, and
anything that depends on those subprojects will fail to build unless
the parent is available within the local repository.

We should adjust our testing procedures, CI builds, etc. such that
this fails going forward, but for now the 1.4.0 artifacts in Maven
Central will not be usable except if the main guacamole-client 1.4.0
source happens to already have been built locally.

Possible solutions would be:

* Verify there is no issue with publishing the guacamole-client build
artifact in general, and call another vote for including the
erroneously-omitted guacamole-client build artifact within 1.4.0. If
that vote passes, we push the artifact. This feels to me like it would
be within policy, but I'm not 100% positive.

* Get started on a 1.4.1 release to patch the issue.

If at all possible, my personal preference would be to avoid doing an
entire release for a binary-only issue relevant only to the Maven
upload. That said, if there _is_ an issue with uploading the
guacamole-client artifact, then a 1.4.1 is unavoidable.

- Mike

[ANNOUNCE] Apache Guacamole 1.4.0

[Mike Jumper]

The Apache Guacamole community is proud to announce the release of
Apache Guacamole 1.4.0.

Apache Guacamole is a clientless remote desktop gateway which supports
standard protocols like VNC, RDP, and SSH. We call it "clientless"
because no plugins or client software are required; once Guacamole is
installed on a server, all you need to access your desktops is a web
browser.

The 1.4.0 release features support for connection tiling, broadcasting
keyboard events across multiple connections, and authentication with
encrypted and signed JSON. Established support for single sign-on has
been improved, multi-touch support for RDP has been added, and
problems with audio input support for RDP have been corrected.

A full list of the changes in this release, along with links to
downloads and updated documentation, can be found in the release
notes:

http://guacamole.apache.org/releases/1.4.0/

For more information on Apache Guacamole, please see:

http://guacamole.apache.org/

Thanks and Happy New Year!

The Apache Guacamole Community

[RESULT] [VOTE] Release Apache Guacamole 1.4.0 (RC1)

[Mike Jumper]

On Wed, Dec 29, 2021 at 7:10 PM Mike Jumper  wrote:
>
> Hello all,
>
> The first release candidate for Apache Guacamole 1.4.0 has been
> uploaded and is ready for VOTE. The draft release notes (along with
> links to artifacts, signatures/checksums, and updated documentation)
> can be found here:
>
> http://guacamole.apache.org/releases/1.4.0/
>
> The git tag for all relevant repositories is "1.4.0-RC1":
>
> https://github.com/apache/guacamole-client/tree/1.4.0-RC1
> https://github.com/apache/guacamole-server/tree/1.4.0-RC1
> https://github.com/apache/guacamole-manual/tree/1.4.0-RC1
>
> Build instructions are included in the manual, which is part of the
> updated documentation referenced above. For convenience:
>
> http://guacamole.apache.org/doc/1.4.0/gug/installing-guacamole.html
>
> Maven artifacts for guacamole-common, guacamole-common-js, and
> guacamole-ext can be found in the following staging repository:
>
> https://repository.apache.org/content/repositories/orgapacheguacamole-1013
>
> Source and binary distributions (also linked within the release notes):
>
> https://dist.apache.org/repos/dist/dev/guacamole/1.4.0-RC1/
>
> Artifacts have been signed with the "mjum...@apache.org" key listed in:
>
> https://dist.apache.org/repos/dist/dev/guacamole/KEYS
>
> Please review and vote:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.


The VOTE to release RC1 of Apache Guacamole 1.4.0 is now closed. With
a total of +4 binding votes from the PMC, +2 from committers and the
community, and NO -1 votes, the VOTE passes. Overall vote breakdown is
as follows:

+1 Michael Jumper (binding)
+1 Carl Harris (binding)
+1 Nick Couchman (binding)
+1 James Muehlner (binding)
+1 Luke
+1 Murat Bülbül

Thanks to everyone who voted. I'll move forward with promoting the
release candidate to release.

- Mike

[VOTE] Release Apache Guacamole 1.4.0 (RC1)

[Mike Jumper]

Hello all,

The first release candidate for Apache Guacamole 1.4.0 has been
uploaded and is ready for VOTE. The draft release notes (along with
links to artifacts, signatures/checksums, and updated documentation)
can be found here:

http://guacamole.apache.org/releases/1.4.0/

The git tag for all relevant repositories is "1.4.0-RC1":

https://github.com/apache/guacamole-client/tree/1.4.0-RC1
https://github.com/apache/guacamole-server/tree/1.4.0-RC1
https://github.com/apache/guacamole-manual/tree/1.4.0-RC1

Build instructions are included in the manual, which is part of the
updated documentation referenced above. For convenience:

http://guacamole.apache.org/doc/1.4.0/gug/installing-guacamole.html

Maven artifacts for guacamole-common, guacamole-common-js, and
guacamole-ext can be found in the following staging repository:

https://repository.apache.org/content/repositories/orgapacheguacamole-1013

Source and binary distributions (also linked within the release notes):

https://dist.apache.org/repos/dist/dev/guacamole/1.4.0-RC1/

Artifacts have been signed with the "mjum...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/guacamole/KEYS

Please review and vote:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Here is my +1.

Thanks,

- Mike

Re: [DISCUSS] Bump guacamole-vault-* and event API improvements to 1.5.0?

[Mike Jumper]

On Tue, Dec 28, 2021 at 3:18 PM Nick Couchman  wrote:
>
> On Tue, Dec 28, 2021 at 5:52 PM Mike Jumper  wrote:
>
> > On Mon, Dec 27, 2021 at 8:52 PM Nick Couchman  wrote:
> > >
> > > On Mon, Dec 27, 2021 at 20:51 Mike Jumper  wrote:
> > >
> > > > Hello all,
> > > >
> > > > With everything else for 1.4.0 complete except for minor documentation
> > > > updates, I'd like to propose bumping the new vault support and event
> > API
> > > > improvement to the release that follows 1.4.0 (presumably 1.5.0).
> > > >
> > > > The vault support is currently implemented but blocked from merge due
> > to
> > > > odd license issues with an Azure library that are taking time to chase
> > down
> > > > [1]. The event API improvements are currently incomplete, but
> > completing
> > > > them would touch a large portion of guacamole-common-js. This late
> > into the
> > > > release, I think it would be best to postpone those API improvements to
> > > > reduce the chance of introducing regressions.
> > > >
> > >
> > > Are the event API improvements part of GUACAMOLE-641, or is that another
> > > Jira issue?
> > >
> >
> > This was for the multi-touch support for RDP (RDPEI -
> > https://issues.apache.org/jira/browse/GUACAMOLE-1204). We introduced a
> > new on('thing', ...), off('thing', ...), etc. event subscription API
> > intended to replace the old-style onthing callbacks, but only the
> > touch and mouse support have been migrated. Other events from the
> > various other objects have not been brought up-to-date with the newer
> > API.
> >
> > For example, you can now do on('mousedown', ...) to handle mousedown
> > events, but for keyboard you'll still have to assign a handler to
> > onkeydown.
> >
> >
> It looks like there are several commits, already, for GUACAMOLE-1204, in
> the 1.4.0 code. Is the plan to just leave those and make it a "partial"
> implementation in 1.4.0? Or do you plan to pull those out of the 1.4.0
> release altogether? I have no preference either way, just curious.
>

My plan would be to leave the event API portion of those changes
partial - it's otherwise complete with respect to the functionality
that's explicitly in scope of GUACAMOLE-1204 (the touch support
itself). The remaining API improvements can be safely removed from its
scope.

For the remaining changes, I would create a separate JIRA issue for
the migration of the remaining event targets.

- Mike

Re: [DISCUSS] Bump guacamole-vault-* and event API improvements to 1.5.0?

[Mike Jumper]

On Mon, Dec 27, 2021 at 8:52 PM Nick Couchman  wrote:
>
> On Mon, Dec 27, 2021 at 20:51 Mike Jumper  wrote:
>
> > Hello all,
> >
> > With everything else for 1.4.0 complete except for minor documentation
> > updates, I'd like to propose bumping the new vault support and event API
> > improvement to the release that follows 1.4.0 (presumably 1.5.0).
> >
> > The vault support is currently implemented but blocked from merge due to
> > odd license issues with an Azure library that are taking time to chase down
> > [1]. The event API improvements are currently incomplete, but completing
> > them would touch a large portion of guacamole-common-js. This late into the
> > release, I think it would be best to postpone those API improvements to
> > reduce the chance of introducing regressions.
> >
>
> Are the event API improvements part of GUACAMOLE-641, or is that another
> Jira issue?
>

This was for the multi-touch support for RDP (RDPEI -
https://issues.apache.org/jira/browse/GUACAMOLE-1204). We introduced a
new on('thing', ...), off('thing', ...), etc. event subscription API
intended to replace the old-style onthing callbacks, but only the
touch and mouse support have been migrated. Other events from the
various other objects have not been brought up-to-date with the newer
API.

For example, you can now do on('mousedown', ...) to handle mousedown
events, but for keyboard you'll still have to assign a handler to
onkeydown.

>
> > Any objection to the above?
>
> None, here - I think pushing the 1.4.0 release out sooner is worth
> sacrificing those two improvements.
>

Alrighty - I'll update the JIRA issues and move forward with the docs.

- Mike

[DISCUSS] Bump guacamole-vault-* and event API improvements to 1.5.0?

[Mike Jumper]

Hello all,

With everything else for 1.4.0 complete except for minor documentation
updates, I'd like to propose bumping the new vault support and event API
improvement to the release that follows 1.4.0 (presumably 1.5.0).

The vault support is currently implemented but blocked from merge due to
odd license issues with an Azure library that are taking time to chase down
[1]. The event API improvements are currently incomplete, but completing
them would touch a large portion of guacamole-common-js. This late into the
release, I think it would be best to postpone those API improvements to
reduce the chance of introducing regressions.

Any objection to the above?

- Mike

[1]
https://github.com/apache/guacamole-client/pull/336#issuecomment-997156397

Re: Log4J Vulnerability

[Mike Jumper]

On Mon, Dec 13, 2021, 04:31 Murat BÜLBÜL <1murat.bul...@gmail.com> wrote:

> Hi Team,
>
> I hope you are well.
>
> Does log4j vulnerability affects guacamole? or tomcat?
>

No, Guacamole does not use Log4j. It uses Logback:

http://logback.qos.ch/

- Mike

Re: Version 1.3.0 user group permissions

[Mike Jumper]

On Mon, Oct 4, 2021, 15:19 Nick Couchman  wrote:

> On Mon, Oct 4, 2021 at 5:39 PM Tezarin  wrote:
>
> > Hello,
> >
> > I have upgraded my Docker based Guacamole installation to 1.3.0, in the
> > previous version, I had used a user sync script to allow my corporate
> LDAP
> > users authenticate with their LDAP credentials.
> >
> > I understand the version 1.3.0 has some built-in features which
> eliminates
> > the need for using user sync script but wasn't able to find any
> > documentation on how to implement that. Can someone please shed some
> lights
> > on this and let me know where to start?
> >
> >
> I think you're looking for the JDBC auto-create feature, which is
> documented here:
>
> http://guacamole.apache.org/doc/gug/jdbc-auth.html#jdbc-auth-auto-create
>
> It was added in version 1.2.0 as part of GUACAMOLE-708:
> https://guacamole.apache.org/releases/1.2.0/
> https://issues.apache.org/jira/browse/GUACAMOLE-708


Also, to be clear, you do not need to automatically create users when just
authenticating with LDAP. There is no need for the users to exist at all,
and an empty, auto-created user gets you nothing except when you need
storage for something like TOTP.

For users coming from LDAP, all you should need is to leverage user groups,
and that has been available since 1.0.0.

- Mike

Re: Scope for Next Release (1.4.0?)

[Mike Jumper]

On Sat, May 15, 2021 at 1:04 PM Nick Couchman  wrote:
>
> On Fri, May 14, 2021 at 4:15 PM Mike Jumper  wrote:
>
> > On Fri, May 14, 2021 at 1:03 PM Mike Jumper  wrote:
> >
> > > On Thu, May 13, 2021 at 1:34 PM Nick Couchman  > >
> > > wrote:
> > >
> > >> Hey, everyone,
> > >> Just doing my usual push to try to finalize scope for the next release,
> > >> which I'm guessing we'll call 1.4.0, and start to target a release date.
> > >> I'm currently looking at end of June/beginning of July.
> > >>
> > >> So far, the following issues have already been implemented/fixed:
> > >>
> > >> GUACAMOLE-1190 (Fix guacd binding to IPv6)
> > >> GUACAMOLE-1298 (Enforce size limits with reverse proxy)
> > >> GUACAMOLE-1307 (FreeRDP 2.3.1 build fixes)
> > >> GUACAMOLE-747 (Document branding)
> > >> GUACAMOLE-1025 (Allow QuickConnect to block connection parameters)
> > >> GUACAMOLE-1060 (Handle Nginx body size limit)
> > >> GUACAMOLE-1128 (Add auto-create options in Docker script)
> > >> GUACAMOLE-1133 (Fix VNC connections to MacOS)
> > >> GUACAMOLE-1160 (Fix French translations)
> > >> GUACAMOLE-1174 (Support connecting to K8s Pods with exec)
> > >> GUACAMOLE-1191 (Disable caches not supported by FreeRDP)
> > >> GUACAMOLE-1201 (Fix audio input rate issues)
> > >> GUACAMOLE-1207 (Portuguese translations)
> > >> GUACAMOLE-1259 (Fix double-free in RDP connect)
> > >> GUACAMOLE-1263 (Fix double-free in VNC disconnect)
> > >> GUACAMOLE-1265 (Update Japanese translations)
> > >> GUACAMOLE-1277 (Fix character in French Belgian AZERTY layout)
> > >> GUACAMOLE-1283 (Fix issue with legacy RDP encryption)
> > >> GUACAMOLE-1299 (Fix for session expiration race)
> > >> GUACAMOLE-1302 (Add support for forcing lossless compression)
> > >> GUACAMOLE-1305 (Fix issue with Portuguese Brazilian keyboard layout)
> > >> GUACAMOLE-1316 (Fix OpenID issue on Docker startup script)
> > >> GUACAMOLE-1317 (Fix OpenJDK build issues with later versions)
> > >> GUACAMOLE-1337 (Clean up trailing white space)
> > >> GUACAMOLE-1055 (Improve Russian OSK Latin symbol support)
> > >> GUACAMOLE-1185 (Fix typo in audio-input file)
> > >> GUACAMOLE-1225 (Fix simple typo)
> > >> GUACAMOLE-1227 (Fix libvncclient 0.9.7 build failure)
> > >> GUACAMOLE-1254 (Support util-linux libuuid)
> > >> GUACAMOLE-1334 (Fix OpenID translation mismatch)
> > >>
> > >> In addition to those, I'd nominate the following issues that are
> > >> in-progress to be included:
> > >> GUACAMOLE-1292 (Prompt before closing window)
> > >> GUACAMOLE-1252 (Allow RADIUS NAS IP to be configured)
> > >> GUACAMOLE-1199 (Fix JDBC issue data disappears with TOTP)
> > >> GUACAMOLE-1245 (Add client parameter for WoL port)
> > >> GUACAMOLE-944 (Allow search username in non-DN format)
> > >> GUACAMOLE-343 (Add fields for explicitly disabling recording)
> > >> GUACAMOLE-996 (Add support for group filter)
> > >> GUACAMOLE-680 (Implement logout hook handler)
> > >>
> > >> Beyond those, there are several that have been in progress for a while,
> > >> but
> > >> without much attention, that we could try to include if we can get
> > >> progress
> > >> from the authors (which could include me on a few of these):
> > >> GUACAMOLE-1219 (Limit TOTP by group membership)
> > >> GUACAMOLE-1130 (Limit retrieval of LDAP attributes)
> > >> GUACAMOLE-1099 (Add support for Docker secrets for LDAP)
> > >> GUACAMOLE-1097 (Update Spanish translations)
> > >> GUACAMOLE-536 (Support LDAP direct binding)
> > >> GUACAMOLE-1006 (Implement List properties)
> > >> GUACAMOLE-1056 (Support TOTP time drift tracking)
> > >> GUACAMOLE-968 (Norwegian keymap)
> > >> GUACAMOLE-1005 (Docker support for Tomcat RemoteIP valve)
> > >> GUACAMOLE-1267 (Support VNC disable remote input)
> > >> GUACAMOLE-141 (Full support for SSH keyboard-interactive)
> > >> GUACAMOLE-1113 (Support right modifiers for SSH/Telnet)
> > >> GUACAMOLE-1047 (Notify connecting client on unknown connection ID)
> > >> GUACAMOLE-951 (Support RDP Keyboard Type)
> > >> GUACAMOLE-1094 (Support OpenID overridable response_type)
> > >> GUACAMOLE-124 (Support for FullScreen action)
> > >> GUAC

Re: Build failed in Jenkins: Guacamole » guacamole-server-master-freerdp » 2.1.1,ubuntu #400

[Mike Jumper]

The build is OK - node H42 is just cursed at the moment.

- Mike

On Mon, Aug 9, 2021, 02:23 Apache Jenkins Server 
wrote:

> See <
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-server-master-freerdp/FREERDP_BRANCH=2.1.1,JENKINS_LABEL_EXPRESSION=ubuntu/400/display/redirect
> >
>
> Changes:
>
>
> --
> Started by upstream project "Guacamole/guacamole-server-master-freerdp"
> build number 400
> originally caused by:
>  Started by timer
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on H42 (ubuntu) in workspace <
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-server-master-freerdp/FREERDP_BRANCH=2.1.1,JENKINS_LABEL_EXPRESSION=ubuntu/ws/
> >
> [WS-CLEANUP] Deleting project workspace...
> [WS-CLEANUP] Deferred wipeout is used...
> The recommended git tool is: NONE
> No credentials specified
> Cloning the remote Git repository
> Cloning repository https://github.com/apache/guacamole-server.git
>  > git init <
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-server-master-freerdp/FREERDP_BRANCH=2.1.1,JENKINS_LABEL_EXPRESSION=ubuntu/ws/guacamole-server>
> # timeout=10
> Fetching upstream changes from
> https://github.com/apache/guacamole-server.git
>  > git --version # timeout=10
>  > git --version # 'git version 2.17.1'
>  > git fetch --tags --progress --
> https://github.com/apache/guacamole-server.git
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git config remote.origin.url
> https://github.com/apache/guacamole-server.git # timeout=10
>  > git config --add remote.origin.fetch
> +refs/heads/*:refs/remotes/origin/* # timeout=10
> Avoid second fetch
> Checking out Revision 12b8eac514528d05366281320b7d675c4439eadc
> (origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 12b8eac514528d05366281320b7d675c4439eadc # timeout=10
> Commit message: "GUACAMOLE-1388: Merge ensure RDP-specific resources are
> cleaned up after channel disconnect."
>  > git rev-list --no-walk 12b8eac514528d05366281320b7d675c4439eadc #
> timeout=10
> [ubuntu] $ /bin/sh -xe /tmp/jenkins2946845896249338657.sh
> + cat
> [ubuntu] $ /bin/sh -xe /tmp/jenkins5161215505999269625.sh
> + cat
> [ubuntu] $ /bin/sh -xe /tmp/jenkins2247209689380932560.sh
> + cat
> [ubuntu] $ /bin/sh -xe /tmp/jenkins7035834744682581790.sh
> + + echo
> guac-jenkins-Guacamole-guacamole-server-master-freerdp-FREERDP_BRANCH=2.1.1,JENKINS_LABEL_EXPRESSION=ubuntu-400
> tr A-Z a-z
> + sed s/[^a-z0-9]\+/-/g
> + export
> TAG=guac-jenkins-guacamole-guacamole-server-master-freerdp-freerdp-branch-2-1-1-jenkins-label-expression-ubuntu-400
> + trap docker rmi --force
> guac-jenkins-guacamole-guacamole-server-master-freerdp-freerdp-branch-2-1-1-jenkins-label-expression-ubuntu-400
> || true EXIT
> + docker build --no-cache=true --rm --tag
> guac-jenkins-guacamole-guacamole-server-master-freerdp-freerdp-branch-2-1-1-jenkins-label-expression-ubuntu-400
> .
> Sending build context to Docker daemon  12.11MB
> Step 1/4 : FROM centos:centos7
> Head "https://registry-1.docker.io/v2/library/centos/manifests/centos7":
> unauthorized: incorrect username or password
> + docker rmi --force
> guac-jenkins-guacamole-guacamole-server-master-freerdp-freerdp-branch-2-1-1-jenkins-label-expression-ubuntu-400
> Error: No such image:
> guac-jenkins-guacamole-guacamole-server-master-freerdp-freerdp-branch-2-1-1-jenkins-label-expression-ubuntu-400
> Build step 'Execute shell' marked build as failure
>

Re: Scope for Next Release (1.4.0?)

[Mike Jumper]

On Fri, May 14, 2021 at 1:03 PM Mike Jumper  wrote:

> On Thu, May 13, 2021 at 1:34 PM Nick Couchman 
> wrote:
>
>> Hey, everyone,
>> Just doing my usual push to try to finalize scope for the next release,
>> which I'm guessing we'll call 1.4.0, and start to target a release date.
>> I'm currently looking at end of June/beginning of July.
>>
>> So far, the following issues have already been implemented/fixed:
>>
>> GUACAMOLE-1190 (Fix guacd binding to IPv6)
>> GUACAMOLE-1298 (Enforce size limits with reverse proxy)
>> GUACAMOLE-1307 (FreeRDP 2.3.1 build fixes)
>> GUACAMOLE-747 (Document branding)
>> GUACAMOLE-1025 (Allow QuickConnect to block connection parameters)
>> GUACAMOLE-1060 (Handle Nginx body size limit)
>> GUACAMOLE-1128 (Add auto-create options in Docker script)
>> GUACAMOLE-1133 (Fix VNC connections to MacOS)
>> GUACAMOLE-1160 (Fix French translations)
>> GUACAMOLE-1174 (Support connecting to K8s Pods with exec)
>> GUACAMOLE-1191 (Disable caches not supported by FreeRDP)
>> GUACAMOLE-1201 (Fix audio input rate issues)
>> GUACAMOLE-1207 (Portuguese translations)
>> GUACAMOLE-1259 (Fix double-free in RDP connect)
>> GUACAMOLE-1263 (Fix double-free in VNC disconnect)
>> GUACAMOLE-1265 (Update Japanese translations)
>> GUACAMOLE-1277 (Fix character in French Belgian AZERTY layout)
>> GUACAMOLE-1283 (Fix issue with legacy RDP encryption)
>> GUACAMOLE-1299 (Fix for session expiration race)
>> GUACAMOLE-1302 (Add support for forcing lossless compression)
>> GUACAMOLE-1305 (Fix issue with Portuguese Brazilian keyboard layout)
>> GUACAMOLE-1316 (Fix OpenID issue on Docker startup script)
>> GUACAMOLE-1317 (Fix OpenJDK build issues with later versions)
>> GUACAMOLE-1337 (Clean up trailing white space)
>> GUACAMOLE-1055 (Improve Russian OSK Latin symbol support)
>> GUACAMOLE-1185 (Fix typo in audio-input file)
>> GUACAMOLE-1225 (Fix simple typo)
>> GUACAMOLE-1227 (Fix libvncclient 0.9.7 build failure)
>> GUACAMOLE-1254 (Support util-linux libuuid)
>> GUACAMOLE-1334 (Fix OpenID translation mismatch)
>>
>> In addition to those, I'd nominate the following issues that are
>> in-progress to be included:
>> GUACAMOLE-1292 (Prompt before closing window)
>> GUACAMOLE-1252 (Allow RADIUS NAS IP to be configured)
>> GUACAMOLE-1199 (Fix JDBC issue data disappears with TOTP)
>> GUACAMOLE-1245 (Add client parameter for WoL port)
>> GUACAMOLE-944 (Allow search username in non-DN format)
>> GUACAMOLE-343 (Add fields for explicitly disabling recording)
>> GUACAMOLE-996 (Add support for group filter)
>> GUACAMOLE-680 (Implement logout hook handler)
>>
>> Beyond those, there are several that have been in progress for a while,
>> but
>> without much attention, that we could try to include if we can get
>> progress
>> from the authors (which could include me on a few of these):
>> GUACAMOLE-1219 (Limit TOTP by group membership)
>> GUACAMOLE-1130 (Limit retrieval of LDAP attributes)
>> GUACAMOLE-1099 (Add support for Docker secrets for LDAP)
>> GUACAMOLE-1097 (Update Spanish translations)
>> GUACAMOLE-536 (Support LDAP direct binding)
>> GUACAMOLE-1006 (Implement List properties)
>> GUACAMOLE-1056 (Support TOTP time drift tracking)
>> GUACAMOLE-968 (Norwegian keymap)
>> GUACAMOLE-1005 (Docker support for Tomcat RemoteIP valve)
>> GUACAMOLE-1267 (Support VNC disable remote input)
>> GUACAMOLE-141 (Full support for SSH keyboard-interactive)
>> GUACAMOLE-1113 (Support right modifiers for SSH/Telnet)
>> GUACAMOLE-1047 (Notify connecting client on unknown connection ID)
>> GUACAMOLE-951 (Support RDP Keyboard Type)
>> GUACAMOLE-1094 (Support OpenID overridable response_type)
>> GUACAMOLE-124 (Support for FullScreen action)
>> GUACAMOLE-577 (Support proxy configuration for LDAP connections)
>> GUACAMOLE-989 (Implement keyboard lock support)
>>
>> Anything we want to knock off the list? Any that we should add?
>>
>
> Checking the commits merged since 1.3.0, I think there are a few issues
> missing from the already implemented/included list:
>
> https://issues.apache.org/jira/browse/GUACAMOLE-770 (Support for
> resetting TOTP within UI)
> https://issues.apache.org/jira/browse/GUACAMOLE-773 (Update webapp
> dependencies)
> https://issues.apache.org/jira/browse/GUACAMOLE-890 (Reduce Docker image
> privileges)
> https://issues.apache.org/jira/browse/GUACAMOLE-986 (Properly document
> non-nullable types)
> https://issues.apache.org/jira/browse/GUACAMOLE-1204 (RDP support for
> touch event pass-through)
> https://issues.apache.org/jira/browse

Re: Scope for Next Release (1.4.0?)

[Mike Jumper]

On Thu, May 13, 2021 at 2:17 PM Nick Couchman  wrote:

> On Thu, May 13, 2021 at 4:56 PM Alexander 
> wrote:
>
> > Plase add this: GUACAMOLE-1293
> > Alert users when
> > admins connect to their session
> >
> >
> https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-1293?filter=allopenissues
> >
>
> My concern with adding this is that there has been no activity of this
> issue at all, yet - there is no pull request submitted, nor has anyone
> volunteered to work on it. If someone would like to commit to working on it
> over the next couple of weeks to add it to the 1.4.0 release, I'm happy to
> consider it. Otherwise it'll have to wait until someone volunteers.
>

I would also be -1 on including GUACAMOLE-1293 in scope unless progress is
already made:

The nature of the issue would require defining some representation and
transport for the alert, and the question of whether that alert is
facilitated by the Guacamole protocol via guacd, via instructions injected
by the webapp, or via some external service like a REST endpoint would need
to be addressed.

I'm not against the development of the feature in general, but IMHO it's
too complex to be added to the proposed release scope if it's not already
well-understood and underway.

- Mike

Re: Scope for Next Release (1.4.0?)

[Mike Jumper]

On Thu, May 13, 2021 at 1:34 PM Nick Couchman 
wrote:

> Hey, everyone,
> Just doing my usual push to try to finalize scope for the next release,
> which I'm guessing we'll call 1.4.0, and start to target a release date.
> I'm currently looking at end of June/beginning of July.
>
> So far, the following issues have already been implemented/fixed:
>
> GUACAMOLE-1190 (Fix guacd binding to IPv6)
> GUACAMOLE-1298 (Enforce size limits with reverse proxy)
> GUACAMOLE-1307 (FreeRDP 2.3.1 build fixes)
> GUACAMOLE-747 (Document branding)
> GUACAMOLE-1025 (Allow QuickConnect to block connection parameters)
> GUACAMOLE-1060 (Handle Nginx body size limit)
> GUACAMOLE-1128 (Add auto-create options in Docker script)
> GUACAMOLE-1133 (Fix VNC connections to MacOS)
> GUACAMOLE-1160 (Fix French translations)
> GUACAMOLE-1174 (Support connecting to K8s Pods with exec)
> GUACAMOLE-1191 (Disable caches not supported by FreeRDP)
> GUACAMOLE-1201 (Fix audio input rate issues)
> GUACAMOLE-1207 (Portuguese translations)
> GUACAMOLE-1259 (Fix double-free in RDP connect)
> GUACAMOLE-1263 (Fix double-free in VNC disconnect)
> GUACAMOLE-1265 (Update Japanese translations)
> GUACAMOLE-1277 (Fix character in French Belgian AZERTY layout)
> GUACAMOLE-1283 (Fix issue with legacy RDP encryption)
> GUACAMOLE-1299 (Fix for session expiration race)
> GUACAMOLE-1302 (Add support for forcing lossless compression)
> GUACAMOLE-1305 (Fix issue with Portuguese Brazilian keyboard layout)
> GUACAMOLE-1316 (Fix OpenID issue on Docker startup script)
> GUACAMOLE-1317 (Fix OpenJDK build issues with later versions)
> GUACAMOLE-1337 (Clean up trailing white space)
> GUACAMOLE-1055 (Improve Russian OSK Latin symbol support)
> GUACAMOLE-1185 (Fix typo in audio-input file)
> GUACAMOLE-1225 (Fix simple typo)
> GUACAMOLE-1227 (Fix libvncclient 0.9.7 build failure)
> GUACAMOLE-1254 (Support util-linux libuuid)
> GUACAMOLE-1334 (Fix OpenID translation mismatch)
>
> In addition to those, I'd nominate the following issues that are
> in-progress to be included:
> GUACAMOLE-1292 (Prompt before closing window)
> GUACAMOLE-1252 (Allow RADIUS NAS IP to be configured)
> GUACAMOLE-1199 (Fix JDBC issue data disappears with TOTP)
> GUACAMOLE-1245 (Add client parameter for WoL port)
> GUACAMOLE-944 (Allow search username in non-DN format)
> GUACAMOLE-343 (Add fields for explicitly disabling recording)
> GUACAMOLE-996 (Add support for group filter)
> GUACAMOLE-680 (Implement logout hook handler)
>
> Beyond those, there are several that have been in progress for a while, but
> without much attention, that we could try to include if we can get progress
> from the authors (which could include me on a few of these):
> GUACAMOLE-1219 (Limit TOTP by group membership)
> GUACAMOLE-1130 (Limit retrieval of LDAP attributes)
> GUACAMOLE-1099 (Add support for Docker secrets for LDAP)
> GUACAMOLE-1097 (Update Spanish translations)
> GUACAMOLE-536 (Support LDAP direct binding)
> GUACAMOLE-1006 (Implement List properties)
> GUACAMOLE-1056 (Support TOTP time drift tracking)
> GUACAMOLE-968 (Norwegian keymap)
> GUACAMOLE-1005 (Docker support for Tomcat RemoteIP valve)
> GUACAMOLE-1267 (Support VNC disable remote input)
> GUACAMOLE-141 (Full support for SSH keyboard-interactive)
> GUACAMOLE-1113 (Support right modifiers for SSH/Telnet)
> GUACAMOLE-1047 (Notify connecting client on unknown connection ID)
> GUACAMOLE-951 (Support RDP Keyboard Type)
> GUACAMOLE-1094 (Support OpenID overridable response_type)
> GUACAMOLE-124 (Support for FullScreen action)
> GUACAMOLE-577 (Support proxy configuration for LDAP connections)
> GUACAMOLE-989 (Implement keyboard lock support)
>
> Anything we want to knock off the list? Any that we should add?
>

Checking the commits merged since 1.3.0, I think there are a few issues
missing from the already implemented/included list:

https://issues.apache.org/jira/browse/GUACAMOLE-770 (Support for resetting
TOTP within UI)
https://issues.apache.org/jira/browse/GUACAMOLE-773 (Update webapp
dependencies)
https://issues.apache.org/jira/browse/GUACAMOLE-890 (Reduce Docker image
privileges)
https://issues.apache.org/jira/browse/GUACAMOLE-986 (Properly document
non-nullable types)
https://issues.apache.org/jira/browse/GUACAMOLE-1204 (RDP support for touch
event pass-through)
https://issues.apache.org/jira/browse/GUACAMOLE-1218 (guacamole-auth-json)
https://issues.apache.org/jira/browse/GUACAMOLE-1276 (Offset truncated to
32 bits in RDP)
https://issues.apache.org/jira/browse/GUACAMOLE-1284
(OPENID_MAX_TOKEN_VALIDITY variable for Docker)
https://issues.apache.org/jira/browse/GUACAMOLE-1291 (Korean translation)
https://issues.apache.org/jira/browse/GUACAMOLE-1339 (Spanish translation
updates)

Additionally, the following issue was listed as possible to exclude from
scope, but has associated commits merged:

https://issues.apache.org/jira/browse/GUACAMOLE-1245 (Configuration option
for WoL port)

I think we should also include the migration away from DocBook, as it would

Re: Download links for Apache Guacamole 1.3.0 are broken

[Mike Jumper]

Retesting the response from closer.cgi, it looks like Infra has restored
things and downloads are back to normal.

- Mike


On Wed, Apr 21, 2021 at 10:56 PM Mike Jumper  wrote:

> Thanks for the heads up. This looks to be a recent issue with the ASF
> "closer.cgi" script that has broken download pages using the
> "closer.cgi?action=download=FILENAME" link format:
>
>
> https://issues.apache.org/jira/browse/INFRA-21767?focusedCommentId=17327019=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17327019
>
> I expect Infra will be working to correct the script to undo the breakage.
> Either way, an alternative URL format is suggested at the above issue that
> _does_ work. I'll get some changes going to migrate to that format.
>
> - Mike
>
>
> On Wed, Apr 21, 2021 at 10:40 PM Van.F 
> wrote:
>
>> All of the download links for Apache Guacamole 1.3.0 are broken and
>> instead open a distribution directory instead.The links I'm referring to
>> are located here: https://guacamole.apache.org/releases/1.3.0/
>> Thanks,Van <https://guacamole.apache.org/releases/1.3.0/Thanks,Van>
>
>

Re: Download links for Apache Guacamole 1.3.0 are broken

[Mike Jumper]

Thanks for the heads up. This looks to be a recent issue with the ASF
"closer.cgi" script that has broken download pages using the
"closer.cgi?action=download=FILENAME" link format:

https://issues.apache.org/jira/browse/INFRA-21767?focusedCommentId=17327019=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17327019

I expect Infra will be working to correct the script to undo the breakage.
Either way, an alternative URL format is suggested at the above issue that
_does_ work. I'll get some changes going to migrate to that format.

- Mike


On Wed, Apr 21, 2021 at 10:40 PM Van.F  wrote:

> All of the download links for Apache Guacamole 1.3.0 are broken and
> instead open a distribution directory instead.The links I'm referring to
> are located here: https://guacamole.apache.org/releases/1.3.0/
> Thanks,Van 

Re: [DISCUSS] Migrate guacamole-manual away from DocBook?

[Mike Jumper]

I've created a quick test using pandoc to translate the entire manual into
reStructuredText and Asciidoc for comparison.

reStructuredText:

https://gist.githubusercontent.com/mike-jumper/b93ef997e83d8565cf46b5bff71845b7/raw/7910262cf97247fcbb4053ed8ab33bcb40710e8d/gug.rst

Asciidoc:

https://gist.githubusercontent.com/mike-jumper/b93ef997e83d8565cf46b5bff71845b7/raw/7910262cf97247fcbb4053ed8ab33bcb40710e8d/gug.adoc

reStructuredText definitely seems much more readable in text form (compare
the tables and lists within the "Optional dependencies" sections). Changing
their contents, resizing columns, etc. looks like it would be painful,
though, and the document format appears to rely heavily on indentation
(like Python).

Asciidoc seems to require a good deal of technical markup even to create a
table, and the syntax seems more obscure.

- Mike


On Wed, Apr 21, 2021 at 1:43 PM Ivanmarcus  wrote:

> Good morning all,
>
> Not sure I can contribute anything much on the two systems Mike's
> mentioned, but I've some related comments, for what they're worth:
>
> In general I've found the present documentation to be clearly written
> and formatted well, albeit (as with all documentation) it takes a little
> time to get used to the writer's intentions.
>
> I think the presentation is much better than many other project docs
> I've seen. Unless there was a compelling need or evidence to change the
> presentation per se I suggest it'd be a positive if something similar to
> the current output format could be retained.
>
>  From an input perspective, this may be at complete odds with what I've
> just said, but almost everyone will know how to fundamentally edit text
> documents, whereas understanding and hand-editing XML etc is simply an
> arse (well, to me it is!). So, not knowing anything about the
> possibilities, a system that is as similar as possible to the way people
> would do it using something like LibreOffice or similar should be the
> most universally usable. Pretty much simple WYSIWYG.
>
>  From the extremely brief look I've just taken at Asciidoc it's clearly
> not WYSIWYG? This may be ok for those who're used to cli/cryptic
> methodologies, but that certainly isn't everyone, and it doesn't make it
> easy (setting aside the 'purety' argument :-). People who may be good at
> writing clear documentation may not be coders, and could be well put off
> by the need to do so simply in order to present their writing. So, if
> there's an intent to encourage input from others I don't see this sort
> of thing to be the way forward.
>
> Of course I could have got a hold of completely the wrong end of the
> stick in which case feel free to ignore me, but if I search for 'online
> WYSIWYG editor' and 'wiki WYSIWYG editor' I get quite a few results.
> I've no experience with any of them, so can't provide any further
> insight at this point, but perhaps someone on this list will have, and
> could comment?
>
> As for offline docs - where it's significant my personal preference is
> usually for PDF because it retains the formatting that (usually) makes
> documents easier to read. Long plain text docs can be difficult given
> the absence of various visual cues to certain sections, and emphasis
> where useful etc. For shorter things text is fine, but that's not
> applicable to Guacamole IMV.
>
> Cheers, Luke.
>
> On 21/04/21 10:20 am, Mike Jumper wrote:
> > I've been thinking recently that the current guacamole-manual is not very
> > approachable with respect to contributions, and that members of the
> > community that might want to contribute to the manual may be turned off
> by
> > the complexity/unfamiliarity of DocBook and XML. It'd be nice if
> improving
> > the manual were as simple as editing a text document.
> >
> > Thoughts? Asciidoc seems a common alternative that is compatible with
> > DocBook.
> >
> > - Mike
> >
>

Re: Using Guacamole fills up Linux Host System Device Volume and eventually causes host crash

[Mike Jumper]

On Sun, Apr 11, 2021 at 12:28 AM Oyvind <100271.2...@compuserve.com> wrote:

> I have Guacamole 1.3.0 installed in a container on my QNAP host system.
> Using Guacamole to Connect to a Remote computer, causes the exhaustion of
> certain host system volumes, and eventually the host will crash.
>
> ...
>
> When checking the host file system, I can see that when I use Guacamole to
> connect to a remote device, the following system storage space is gradually
> filled up until it eventually exhaust, causing the above error message:
>
> ...
>
> Rebooting the host server restores full operation again, for a while.
>
> I have several different QNAP NAS models with identical base OS/Docker
> configuration running many different containerized applications without
> similar problems. This situation *only* happens when I use Guacamole to
> connect to any remote computer.  Only launching the Guacamole main menu
> does not cause any problems, but as soon as I connect to a remote device,
> this System Storage Mount begins to fill up at a pace of approximately
> 100K/Sec.  According to QNAP, this mounted device is designed to store
> system advanced libraries and tools/utilities. If I disconnect from the
> remote computer and returns back to the Guacamole main menu, the filling of
> this device mount stops. If I connect again, it continues to fill.
>
>
> Any ideas/suggestions to help me debug this situation is much appreciated.
>

Have you checked the contents of that filesystem? Perhaps taking a look
over the specific files will show what exactly is being stored there and
why it's growing.

Michael Jumper
CEO, Lead Developer
Glyptodon Inc .

Re: Support Needed

[Mike Jumper]

On Thu, Mar 4, 2021 at 9:13 AM  wrote:

> Dear,
>
> We are using Guacamole in our environment to access AWS EC2 Instances.
>
> We are further developing on solution to automate access to machine on
> button click.
>
> For this we want to know,
>
> 1)  How to disable authentication while login to Guacamole Server
>

You should *never* do this. See:
http://guacamole.apache.org/faq/#disable-auth


> 2)  How guacamole server generate URL on machine click.
> 3)  We need this url so that we can open this url on button click.
>

The way to automatically log in users based on an external source of
authentication, automatically direct users to a connection based on an
external source of authorization/configuration, etc. is through writing a
Guacamole extension that does exactly that.

There are existing extensions aimed at making this easier. The
guacamole-auth-json extension was written at my day job to do this. It has
since become part of the guacamole-client codebase:

https://github.com/apache/guacamole-client/tree/master/extensions/guacamole-auth-json

See also:

https://issues.apache.org/jira/browse/GUACAMOLE-1218

Michael Jumper
CEO, Lead Developer
Glyptodon Inc .

Re: Input device for signature

[Mike Jumper]

On Sat, Feb 20, 2021 at 1:08 PM Narasimhan Rajamahendran <
narasimhan.mahend...@gmail.com> wrote:

> Hello team,
>
> I want to use Wacom STU signature pad for signing documents. But currently
> the device not recognized by Guacamole for an application to detect and
> enable signature capture. Requesting assistance in achieving the same.


Can you retest with a fresh build of guacamole-client and guacamole-server
from git master? Support for pass-through of multi-touch events was
recently merged. I'm not sure whether signature capture pads involve the
same sort of events, but it's worth a shot.

Michael Jumper
CEO, Lead Developer
Glyptodon Inc .

Re: Guacamole 1.3 download links are HTTP - Blocked by Chrome

[Mike Jumper]

On Wed, Feb 3, 2021 at 3:37 AM Vincent Sherwood 
wrote:

> The download links on https://guacamole.apache.org/releases/1.3.0/ are
> all HTTP instead of HTTPS. As a result they are now blocked by default in
> the Chrome browser. If you click on any of the links it will silently
> ignore the file.
>

Thanks for letting us know. I can confirm this behavior when the website is
visited over HTTPS. If visiting over HTTP, this does not occur.

I'll move forward with updating the site to use HTTPS for download links.

- Mike

Re: Build failed in Jenkins: Guacamole » guacamole-server-master-centos » 7,ubuntu #184

[Mike Jumper]

I believe I made that config change to the relevant builds just prior to
merging the latest gcrypt-related changes (not all environments apparently
require gcrypt for their libvncclient).

Did you make additional changes?

- Mike

On Sun, Jan 24, 2021, 15:50 Nick Couchman  wrote:

> On Sun, Jan 24, 2021 at 6:43 PM Nick Couchman  wrote:
>
> > Builds are back to normal, now, but does anything need to be adjusted in
> > the builds such that the gcrypt-dev/devel package is installed?
> >
> >
> Nevermind...I found the configs and added the libgrcrypt-dev or
> libgcrypt-devel package to the build environment.
>
> -Nick
>
> >
>

Re: Build failed in Jenkins: Guacamole » guacamole-server-master-centos » 7,ubuntu #184

[Mike Jumper]

We should probably have another sanity check at build time, similar to the
one for libssh2 (might end up looking a bit different given that
libvncclient provides its own handy macro for determining whether the
library uses gcrypt):

https://github.com/apache/guacamole-server/blob/6d526cb60f3601c4d73f00fbd0daa72457d7df84/configure.ac#L919-L938

I think part of this is that the -dev / -devel package for libvncclient on
the various distributions is technically incorrect (if it's build against
libgcrypt, the -dev package should depend on libgcrypt-dev), but our build
should at least display a meaningful warning if this condition occurs.

- Mike


On Sat, Jan 23, 2021 at 5:19 AM Nick Couchman 
wrote:

> Welp, looks like I have a little more work to do on this one...
>
> -Nick
>
> On Sat, Jan 23, 2021 at 6:44 AM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-server-master-centos/CENTOS_RELEASE=7,JENKINS_LABEL_EXPRESSION=ubuntu/184/display/redirect?page=changes
> > >
> >
> > Changes:
> >
> > [Nick Couchman] GUACAMOLE-1133: initialize GCrypt in VNC protocol prior
> to
> > client
> >
> >
> > --
> > [...truncated 158.79 KB...]
> >   CC   libguac_la-id.lo
> >   CC   libguac_la-palette.lo
> >   CC   libguac_la-parser.lo
> >   CC   libguac_la-pool.lo
> >   CC   libguac_la-protocol.lo
> >   CC   libguac_la-raw_encoder.lo
> >   CC   libguac_la-socket.lo
> >   CC   libguac_la-socket-broadcast.lo
> >   CC   libguac_la-socket-fd.lo
> >   CC   libguac_la-socket-nest.lo
> >   CC   libguac_la-socket-tee.lo
> >   CC   libguac_la-string.lo
> >   CC   libguac_la-timestamp.lo
> >   CC   libguac_la-unicode.lo
> >   CC   libguac_la-user.lo
> >   CC   libguac_la-user-handlers.lo
> >   CC   libguac_la-user-handshake.lo
> >   CC   libguac_la-wait-fd.lo
> >   CC   libguac_la-wol.lo
> >   CC   libguac_la-encode-webp.lo
> >   CC   libguac_la-socket-ssl.lo
> >   CCLD libguac.la
> > make[3]: Leaving directory `/build/guacamole-server/src/libguac'
> > Making all in tests
> > make[3]: Entering directory `/build/guacamole-server/src/libguac/tests'
> > make[3]: Nothing to be done for `all'.
> > make[3]: Leaving directory `/build/guacamole-server/src/libguac/tests'
> > make[2]: Leaving directory `/build/guacamole-server/src/libguac'
> > Making all in src/common
> > make[2]: Entering directory `/build/guacamole-server/src/common'
> > Making all in .
> > make[3]: Entering directory `/build/guacamole-server/src/common'
> >   CC   libguac_common_la-io.lo
> >   CC   libguac_common_la-blank_cursor.lo
> >   CC   libguac_common_la-clipboard.lo
> >   CC   libguac_common_la-cursor.lo
> >   CC   libguac_common_la-display.lo
> >   CC   libguac_common_la-dot_cursor.lo
> >   CC   libguac_common_la-ibar_cursor.lo
> >   CC   libguac_common_la-iconv.lo
> >   CC   libguac_common_la-json.lo
> >   CC   libguac_common_la-list.lo
> >   CC   libguac_common_la-pointer_cursor.lo
> >   CC   libguac_common_la-recording.lo
> >   CC   libguac_common_la-rect.lo
> >   CC   libguac_common_la-string.lo
> >   CC   libguac_common_la-surface.lo
> >   CCLD libguac_common.la
> > make[3]: Leaving directory `/build/guacamole-server/src/common'
> > Making all in tests
> > make[3]: Entering directory `/build/guacamole-server/src/common/tests'
> > make[3]: Nothing to be done for `all'.
> > make[3]: Leaving directory `/build/guacamole-server/src/common/tests'
> > make[2]: Leaving directory `/build/guacamole-server/src/common'
> > Making all in src/common-ssh
> > make[2]: Entering directory `/build/guacamole-server/src/common-ssh'
> > Making all in .
> > make[3]: Entering directory `/build/guacamole-server/src/common-ssh'
> >   CC   libguac_common_ssh_la-buffer.lo
> >   CC   libguac_common_ssh_la-dsa-compat.lo
> >   CC   libguac_common_ssh_la-rsa-compat.lo
> >   CC   libguac_common_ssh_la-sftp.lo
> >   CC   libguac_common_ssh_la-ssh.lo
> >   CC   libguac_common_ssh_la-key.lo
> >   CC   libguac_common_ssh_la-user.lo
> >   CCLD libguac_common_ssh.la
> > make[3]: Leaving directory `/build/guacamole-server/src/common-ssh'
> > Making all in tests
> > make[3]: Entering directory
> `/build/guacamole-server/src/common-ssh/tests'
> > make[3]: Nothing to be done for `all'.
> > make[3]: Leaving directory `/build/guacamole-server/src/common-ssh/tests'
> > make[2]: Leaving directory `/build/guacamole-server/src/common-ssh'
> > Making all in src/terminal
> > make[2]: Entering directory `/build/guacamole-server/src/terminal'
> >   CC   libguac_terminal_la-buffer.lo
> >   CC   libguac_terminal_la-char_mappings.lo
> >   CC   libguac_terminal_la-color-scheme.lo
> >   CC   libguac_terminal_la-common.lo
> >   CC   libguac_terminal_la-display.lo
> >   CC   

Re: Guacamole server setup on Linux

[Mike Jumper]

On Wed, Jan 20, 2021 at 11:38 PM Trakroo, Shwaita <
shwaita.trak...@tektronix.com> wrote:

> Hello,
>
> How can we build Guacamole server on Windows 10 machine?


Can you clarify what you're looking to accomplish by doing so?

Much of guacamole-server relies on POSIX behavior that is unavailable on
Windows, at least not without a specific porting effort. The core libguac
library has been written to be buildable on Windows, and should compile
nicely using the MinGW toolchain, but I don't believe the rest of
guacamole-server can be built in this way.

If you absolutely cannot deploy a Linux server and need to run 100% of
Guacamole on Windows, I think your next best option would still be to
leverage a Linux server via a virtual machine.

Michael Jumper
CEO, Lead Developer
Glyptodon Inc .

[SECURITY] CVE-2020-11997: Apache Guacamole: Inconsistent restriction of connection history visibility

[Mike Jumper]

CVE-2020-11997: Inconsistent restriction of connection history visibility

Versions affected:
Apache Guacamole 1.2.0 and earlier

Description:
Apache Guacamole 1.2.0 and older do not consistently restrict access
to connection history based on user visibility. If multiple users
share access to the same connection, those users may be able to see
which other users have accessed that connection, as well as the IP
addresses from which that connection was accessed, even if those users
do not otherwise have permission to see other users.

Mitigation:
Users of versions of Apache Guacamole 1.2.0 and older should upgrade to 1.3.0.

Credit:
We would like to thank William Le Berre (Synetis) for reporting this issue.

[ANNOUNCE] Apache Guacamole 1.3.0

[Mike Jumper]

The Apache Guacamole community is proud to announce the release of
Apache Guacamole 1.3.0.

Apache Guacamole is a clientless remote desktop gateway which supports
standard protocols like VNC, RDP, and SSH. We call it "clientless"
because no plugins or client software are required; once Guacamole is
installed on a server, all you need to access your desktops is a web
browser.

The 1.3.0 release features support for automatically prompting users
for their remote desktop credentials, user group support for both CAS
and OpenID, and several bug fixes.

A full list of the changes in this release, along with links to
downloads and updated documentation, can be found in the release
notes:

http://guacamole.apache.org/releases/1.3.0/

For more information on Apache Guacamole, please see:

http://guacamole.apache.org/

Thanks and Happy New Year!

The Apache Guacamole Community

[RESULT] [VOTE] Release Apache Guacamole 1.3.0 (RC1)

[Mike Jumper]

On Mon, Dec 28, 2020 at 6:59 PM Mike Jumper  wrote:

> Hello all,
>
> The first release candidate for Apache Guacamole 1.3.0 has been uploaded
> and is ready for VOTE. The draft release notes (along with links to
> artifacts, signatures/checksums, and updated documentation) can be found
> here:
>
> http://guacamole.apache.org/releases/1.3.0/
>
> The git tag for all relevant repositories is "1.3.0-RC1":
>
> https://github.com/apache/guacamole-client/tree/1.3.0-RC1
> https://github.com/apache/guacamole-server/tree/1.3.0-RC1
> https://github.com/apache/guacamole-manual/tree/1.3.0-RC1
>
> Build instructions are included in the manual, which is part of the
> updated documentation referenced above. For convenience:
>
> http://guacamole.apache.org/doc/1.3.0/gug/installing-guacamole.html
>
> Maven artifacts for guacamole-common, guacamole-common-js, and
> guacamole-ext can be found in the following staging repository:
>
> https://repository.apache.org/content/repositories/orgapacheguacamole-1012
>
> Source and binary distributions (also linked within the release notes):
>
> https://dist.apache.org/repos/dist/dev/guacamole/1.3.0-RC1/
>
> Artifacts have been signed with the "mjum...@apache.org" key listed in:
>
> https://dist.apache.org/repos/dist/dev/guacamole/KEYS
>
> Please review and vote:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>

The VOTE to release RC1 of Apache Guacamole 1.3.0 is now closed. With a
total of +4 binding votes from the PMC, +2 from the community, and NO -1
votes, the VOTE passes. Overall vote breakdown is as follows:

+1 Michael Jumper (binding)
+1 Nick Couchman (binding)
+1 Tim Worcester
+1 Carl Harris (binding)
+1 Murat Bülbül
+1 Jean-Baptiste Onofré (binding)

Thanks to everyone who voted. I'll move forward with promoting the release
candidate to release.

- Mike

[VOTE] Release Apache Guacamole 1.3.0 (RC1)

[Mike Jumper]

Hello all,

The first release candidate for Apache Guacamole 1.3.0 has been uploaded
and is ready for VOTE. The draft release notes (along with links to
artifacts, signatures/checksums, and updated documentation) can be found
here:

http://guacamole.apache.org/releases/1.3.0/

The git tag for all relevant repositories is "1.3.0-RC1":

https://github.com/apache/guacamole-client/tree/1.3.0-RC1
https://github.com/apache/guacamole-server/tree/1.3.0-RC1
https://github.com/apache/guacamole-manual/tree/1.3.0-RC1

Build instructions are included in the manual, which is part of the updated
documentation referenced above. For convenience:

http://guacamole.apache.org/doc/1.3.0/gug/installing-guacamole.html

Maven artifacts for guacamole-common, guacamole-common-js, and
guacamole-ext can be found in the following staging repository:

https://repository.apache.org/content/repositories/orgapacheguacamole-1012

Source and binary distributions (also linked within the release notes):

https://dist.apache.org/repos/dist/dev/guacamole/1.3.0-RC1/

Artifacts have been signed with the "mjum...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/guacamole/KEYS

Please review and vote:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Here is my +1.

Thanks,

- Mike

Re: Guacamole 1.2 UI throws 403 and 405 for api/token and api/user

[Mike Jumper]

On Wed, Dec 23, 2020, 13:27 Fabian Schrödter 
wrote:

> Dear Guacamole Team,
>
> I am facing an 403 and 405 issue with the login page of guacamole. Fully
> logs and infos are placed at Jira (
> https://issues.apache.org/jira/browse/GUACAMOLE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
> <
> https://issues.apache.org/jira/browse/GUACAMOLE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> >).
> There are no big errors in logs, but certain indications for increasing
> log level of the docker-container (running on K8s) to debug. Any idea how
> to update the log level for guacamole pods?
>

This doesn't sound like it's Guacamole returning these responses. An error
like what you're seeing would be in the logs already without any changes to
log level. There also aren't any cases where the client would cause an HTTP
405 ("Method Not Allowed") when accessing its own REST API.

Is there something on the network between the browser and Guacamole that
might be intercepting these requests and failing?

- Mike

Re: Build failed in Jenkins: Guacamole » guacamole-client-master » ubuntu,jdk_10_latest #22

[Mike Jumper]

Arg, yep ... I'll start digging.

- Mike

On Wed, Dec 16, 2020 at 11:44 AM Nick Couchman  wrote:

> Uh-oh...looks like maybe some incompatibilities with the javax.xml.bind
> stuff and later versions of JDK?
>
> -Nick
>
> On Wed, Dec 16, 2020 at 2:34 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/22/display/redirect?page=changes
> > >
> >
> > Changes:
> >
> > [Mike Jumper] GUACAMOLE-1218: Copy guacamole-auth-json source tree from
> > glyptodon/guacamole-auth-json at commit
> > f7b2eaf6a65b7cd25fd73437360e36fe46e0bcb9.
> >
> > [Mike Jumper] GUACAMOLE-1218: Refactor org.glyptodon.* packages to
> > org.apache.*
> >
> > [Mike Jumper] GUACAMOLE-1218: Re-license under Apache v2.0.
> >
> > [Mike Jumper] GUACAMOLE-1218: Remove old @author mentions from
> > guacamole-auth-json JavaDoc.
> >
> > [Mike Jumper] GUACAMOLE-1218: Update to version 1.3.0 of guacamole-ext.
> >
> > [Mike Jumper] GUACAMOLE-1218: Refactor guacamole-auth-json's
> > ByteArrayProperty into guacamole-ext.
> >
> > [Mike Jumper] GUACAMOLE-1218: Refactor guacamole-auth-json's
> > StringListProperty into guacamole-ext.
> >
> > [Mike Jumper] GUACAMOLE-1218: Update to latest version of Spring
> Security.
> >
> > [Mike Jumper] GUACAMOLE-1218: Bundle and document the licenses of all
> > guacamole-auth-json dependencies.
> >
> > [Mike Jumper] GUACAMOLE-1218: Replace use of "blacklist" with "denylist".
> >
> > [Mike Jumper] GUACAMOLE-1218: Use diamond operator and multi-catch where
> > possible.
> >
> > [Mike Jumper] GUACAMOLE-1218: Use static instances of Logger per
> > established coding practices.
> >
> >
> > --
> > [...truncated 528.82 KB...]
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/servlet/GuacamoleHTTPTunnelServlet.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/websocket/GuacamoleWebSocketTunnelEndpoint.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/overview-frame.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/package-frame.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/package-summary.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/package-tree.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/io/package-frame.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/io/package-summary.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/io/package-tree.html
> ..
> > .>
> > Generating <
> >
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=jdk_10_latest/ws/guacamole-client/guacamole-common/target/apidocs/org/apache/guacamole/net/package-frame.html
> ..
> > .>
> > Generating <
> >
&

Re: Improve the end user interface

[Mike Jumper]

Can you be more specific?

On Sat, Nov 28, 2020, 18:43 Alexander  wrote:

> Improve the end user interface like:
>
> Termius
> https://termius.com/
>
>
> https://www.microsoft.com/es-mx/p/termius-ssh-client/9nk1gdvpx09v?activetab=pivot:overviewtab
>
> Guacozy
> https://www.youtube.com/watch?v=R5uCPrH9mnw
>
> https://github.com/paidem/guacozy
>
> https://guacozy.readthedocs.io/en/latest/
>

Re: Build failed in Jenkins: Guacamole » guacamole-server-master-freerdp » 2.0.0-rc2,ubuntu #89

[Mike Jumper]

Apparently, FREERDP_ERROR_CONNECT_NO_OR_MISSING_CREDENTIALS is a new
addition in 2.0.0-rc3 and beyond.

- Mike

On Mon, Nov 2, 2020 at 7:36 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://ci-builds.apache.org/job/Guacamole/job/guacamole-server-master-freerdp/FREERDP_BRANCH=2.0.0-rc2,JENKINS_LABEL_EXPRESSION=ubuntu/89/display/redirect?page=changes
> >
>
> Changes:
>
> [Mike Jumper] GUACAMOLE-221: Rely on FreeRDP error code if no RDP
> disconnect reason is available.
>
> [Mike Jumper] GUACAMOLE-221: Increase verbosity of logged FreeRDP-related
> errors.
>
>
> --
> [...truncated 207.10 KB...]
> make[1]: Entering directory `/build/guacamole-server/src/protocols/ssh'
> test -z "libguac-client-ssh.la" || rm -f libguac-client-ssh.la
> rm -f ./so_locations
> rm -rf .libs _libs
> rm -f *.o
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server/src/protocols/ssh'
> Making clean in src/protocols/telnet
> make[1]: Entering directory `/build/guacamole-server/src/protocols/telnet'
> test -z "libguac-client-telnet.la" || rm -f libguac-client-telnet.la
> rm -f ./so_locations
> rm -rf .libs _libs
> rm -f *.o
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server/src/protocols/telnet'
> Making clean in src/protocols/vnc
> make[1]: Entering directory `/build/guacamole-server/src/protocols/vnc'
> test -z "libguac-client-vnc.la" || rm -f libguac-client-vnc.la
> rm -f ./so_locations
> rm -rf .libs _libs
> rm -f *.o
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server/src/protocols/vnc'
> Making clean in src/guacd
> make[1]: Entering directory `/build/guacamole-server/src/guacd'
> test -z " " || rm -f
> rm -rf .libs _libs
>  rm -f guacd
> rm -f *.o
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server/src/guacd'
> Making clean in src/guacenc
> make[1]: Entering directory `/build/guacamole-server/src/guacenc'
>  rm -f guacenc
> rm -rf .libs _libs
> rm -f *.o
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server/src/guacenc'
> Making clean in src/guaclog
> make[1]: Entering directory `/build/guacamole-server/src/guaclog'
>  rm -f guaclog
> rm -rf .libs _libs
> rm -f *.o
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server/src/guaclog'
> make[1]: Entering directory `/build/guacamole-server'
> rm -rf .libs _libs
> rm -f *.lo
> make[1]: Leaving directory `/build/guacamole-server'
>  [91m+ make
>  [0mmake  all-recursive
> make[1]: Entering directory `/build/guacamole-server'
> Making all in src/libguac
> make[2]: Entering directory `/build/guacamole-server/src/libguac'
> Making all in .
> make[3]: Entering directory `/build/guacamole-server/src/libguac'
>   CC   libguac_la-argv.lo
>   CC   libguac_la-audio.lo
>   CC   libguac_la-client.lo
>   CC   libguac_la-encode-jpeg.lo
>   CC   libguac_la-encode-png.lo
>   CC   libguac_la-error.lo
>   CC   libguac_la-hash.lo
>   CC   libguac_la-id.lo
>   CC   libguac_la-palette.lo
>   CC   libguac_la-parser.lo
>   CC   libguac_la-pool.lo
>   CC   libguac_la-protocol.lo
>   CC   libguac_la-raw_encoder.lo
>   CC   libguac_la-socket.lo
>   CC   libguac_la-socket-broadcast.lo
>   CC   libguac_la-socket-fd.lo
>   CC   libguac_la-socket-nest.lo
>   CC   libguac_la-socket-tee.lo
>   CC   libguac_la-string.lo
>   CC   libguac_la-timestamp.lo
>   CC   libguac_la-unicode.lo
>   CC   libguac_la-user.lo
>   CC   libguac_la-user-handlers.lo
>   CC   libguac_la-user-handshake.lo
>   CC   libguac_la-wait-fd.lo
>   CC   libguac_la-wol.lo
>   CC   libguac_la-encode-webp.lo
>   CC   libguac_la-socket-ssl.lo
>   CCLD libguac.la
> make[3]: Leaving directory `/build/guacamole-server/src/libguac'
> Making all in tests
> make[3]: Entering directory `/build/guacamole-server/src/libguac/tests'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `/build/guacamole-server/src/libguac/tests'
> make[2]: Leaving directory `/build/guacamole-server/src/libguac'
> Making all in src/common
> make[2]: Entering directory `/build/guacamole-server/src/common'
> Making all in .
> make[3]: Entering directory `/build/guacamole-server/src/common'
>   CC   libguac_common_la-io.lo
>   CC   libguac_common_la-blank_cursor.lo
>   CC   libguac_common_la-clipboard.lo
>   CC   libguac_common_la-cursor.lo
>   CC   libguac_common_la-display.lo
>   CC   libguac_common_la-dot_cursor.lo
>   CC   libguac_common_la-ibar_cursor.lo
>   CC   li

Re: [DISCUSS] Scope of 1.3.0 release

[Mike Jumper]

OK - looks like there's general consensus on all this. I've created the
"staging/1.3.0" branches for all relevant repositories and tagged all
discussed issues accordingly. The list of all issues in 1.3.0 scope:

GUACAMOLE-221 - Parameter prompting within client interface
GUACAMOLE-753 - Add TOTP auth method to start.sh for Docker image
GUACAMOLE-760 - add timezone info using DB Connection string
GUACAMOLE-793 - CAS Provider returns Group - like LDAP Provider
GUACAMOLE-819 - Documented Duo secret key length is incorrect
GUACAMOLE-857 - Add Docker Image Support for HTTP Header-Based
Authentication
GUACAMOLE-903 - Improved Chinese internationalization support
GUACAMOLE-912 - Fix Guacamole Docker Documentation to indiciate image does
not support LDAP Docker Links
GUACAMOLE-919 - An I/O error occurred while sending to the backend
GUACAMOLE-942 - Query may fail if all connections disconnect while listing
active connections
GUACAMOLE-949 - Remove unused UNIX_TIME macro
GUACAMOLE-980 - used tomcat-jre8 Docker-Image seems to be deprecated
GUACAMOLE-982 - Typo mistake : incorrect the error log message of RDP
GUACAMOLE-987 - ldap-user-attributes is not set via an env
variableGUACAMOLE-1001 - RADIUS Extension Needs Additional Attributes
GUACAMOLE-1021 - Top level organizational level of connection group
repeated when user is in two groups that contain different hosts
GUACAMOLE-1031 - SFTP upload directory ignored
GUACAMOLE-1054 - Improve Russian translation
GUACAMOLE-1078 - Add Catalan Language to Guacamole
GUACAMOLE-1081 - option to convert usernames to all lowercase
GUACAMOLE-1082 - Add guacamole-auth-cas to docker Script
GUACAMOLE-1103 - Typo mistake : the incorrect comment of a variable for the
RDP setting
GUACAMOLE-1107 - "allowed-languages" property incorrectly documented as
"available-languages"
GUACAMOLE-1110 - Size and security improvements for Docker images
GUACAMOLE-1114 - Problem that the guacamole server doesn't destroy some
thread mutexes
GUACAMOLE-1120 - CAS module causes app.js download errors
GUACAMOLE-1122 - Fail in compile of RDP protocol when SSH is unavailable
GUACAMOLE-1123 - Standardize on filtered history query for user and
connection management
GUACAMOLE-1125 - Ctrl+Alt+End(Supr) only working once
GUACAMOLE-1135 - MySQL SSL - Trust Store Paths Expecting URI
GUACAMOLE-1136 - MySQL SSL Client Cert Environment Variables Return Trust
Store
GUACAMOLE-1146 - TOTP authentication fails when totp-period is set
GUACAMOLE-1147 - Add support for additional LDAP properties in Docker
GUACAMOLE-1149 - Login using LDAP fails internally if TOTP is used without
automatic user creation
GUACAMOLE-1150 - Connection group permissions aren't checked correctly
GUACAMOLE-1151 - Add nbproject directory to .gitignore file
GUACAMOLE-1152 - Enabling skip-if-unavailable breaks expired password change
GUACAMOLE-1158 - RDP "disable-copy" flag does not work
GUACAMOLE-1172 - Retrieve groups from OpenID
GUACAMOLE-1181 - Memory allocated for outbound SVC PDUs may not be freed
GUACAMOLE-1182 - Memory allocated for outbound RDP clipboard data is not
properly freed

Corresponding JIRA search:

https://issues.apache.org/jira/browse/GUACAMOLE-1182?jql=project%20%3D%20GUACAMOLE%20AND%20fixVersion%20%3D%201.3.0

- Mike


On Tue, Sep 8, 2020 at 5:50 PM Tim Worcester 
wrote:

> Currently if you use an OIDC solution as a identity provider RDP
> connections don’t really work since Guacamole itself never handles the
> password.  The prompting in GUACAMOLE-221 takes care of that.  (This may
> apply to more than RDP, that was just the use case I ran into)
>
> Thus, I believe that the two issues can be related to the Guacamole OIDC
> auth plugin use case.
>
> On Tue, Sep 8, 2020 at 7:59 PM Mike Jumper  wrote:
>
> > On Tue, Sep 8, 2020 at 9:50 AM Tim Worcester <
> timothy.worces...@gmail.com>
> >
> > wrote:
> >
> >
> >
> > > I would like to vote for GUACAMOLE-1172 to be added in as well, I think
> > it
> >
> > > ties in nicely with the OIDC friendly features being added with
> >
> > > GUACAMOLE-221.
> >
> > >
> >
> >
> >
> > It does look like the PR for GUACAMOLE-1172 is nearing readiness, but can
> >
> > you clarify in what way those changes (support for defining group
> >
> > memberships via OpenID) align with GUACAMOLE-221 (general support for
> >
> > prompting users for remote desktop credentials)?
> >
> >
> >
> > - Mike
> >
> >
>

Re: Memory leak in RDP clipboard redirection

[Mike Jumper]

On Tue, Sep 8, 2020 at 4:07 PM Mike Jumper  wrote:

> On Tue, Sep 8, 2020 at 2:09 PM gabriel sztejnworcel 
> wrote:
>
>> Hi,
>>
>> I think we found a memory leak, I wanted to check with you and consult
>> about the fix.
>>
>> We ran valgrind to check for memory leaks and noticed that each time we
>> copy something through the clipboard, we get a 262144 bytes memory leak in
>> the function guac_rdp_cliprdr_format_data_request. The leak comes from the
>> "output" buffer, which is allocated in the function and later passed to a
>> FreeRDP function through the cliprdr->ClientFormatDataResponse pointer.
>> The
>> buffer is not freed, and it doesn't seem like it's supposed to be freed in
>> the FreeRDP function (since they accept the structure that contains the
>> buffer as a const pointer).
>>
>>
> Yes, I think you're correct.
>
> The fix I suggest (in guac_rdp_cliprdr_format_data_request):
>>
>> - char* output = malloc(GUAC_RDP_CLIPBOARD_MAX_LENGTH);
>>
>> +  char* buf = malloc(GUAC_RDP_CLIPBOARD_MAX_LENGTH);
>> + char* output = buf; // output pointer will change so we store the
>> original value in buf
>>
>
> There already is such a pointer:
>
>
> https://github.com/apache/guacamole-server/blob/382d72a26a04008aa936680deed00e3a31086b1e/src/protocols/rdp/channels/cliprdr.c#L356
>
> - return cliprdr->ClientFormatDataResponse(cliprdr, _response);
>>
>> + UINT result = cliprdr->ClientFormatDataResponse(cliprdr,
>> _response);
>> + free(buf);
>> + return result;
>>
>> Your thoughts?
>>
>
> I agree that we should manually free() the buffer after
> ClientFormatDataResponse() returns. It would be good to also double-check
> whether there are any other similar failures to free memory allocated for
> an outbound PDU that is handed off to FreeRDP but not actually freed
> internally by FreeRDP.
>

I've opened https://issues.apache.org/jira/browse/GUACAMOLE-1182 for this.

- Mike

Re: [DISCUSS] Scope of 1.3.0 release

[Mike Jumper]

On Tue, Sep 8, 2020 at 9:50 AM Tim Worcester 
wrote:

> I would like to vote for GUACAMOLE-1172 to be added in as well, I think it
> ties in nicely with the OIDC friendly features being added with
> GUACAMOLE-221.
>

It does look like the PR for GUACAMOLE-1172 is nearing readiness, but can
you clarify in what way those changes (support for defining group
memberships via OpenID) align with GUACAMOLE-221 (general support for
prompting users for remote desktop credentials)?

- Mike

Re: Memory leak in RDP clipboard redirection

[Mike Jumper]

On Tue, Sep 8, 2020 at 2:09 PM gabriel sztejnworcel 
wrote:

> Hi,
>
> I think we found a memory leak, I wanted to check with you and consult
> about the fix.
>
> We ran valgrind to check for memory leaks and noticed that each time we
> copy something through the clipboard, we get a 262144 bytes memory leak in
> the function guac_rdp_cliprdr_format_data_request. The leak comes from the
> "output" buffer, which is allocated in the function and later passed to a
> FreeRDP function through the cliprdr->ClientFormatDataResponse pointer. The
> buffer is not freed, and it doesn't seem like it's supposed to be freed in
> the FreeRDP function (since they accept the structure that contains the
> buffer as a const pointer).
>
>
Yes, I think you're correct.

The fix I suggest (in guac_rdp_cliprdr_format_data_request):
>
> - char* output = malloc(GUAC_RDP_CLIPBOARD_MAX_LENGTH);
>
> +  char* buf = malloc(GUAC_RDP_CLIPBOARD_MAX_LENGTH);
> + char* output = buf; // output pointer will change so we store the
> original value in buf
>

There already is such a pointer:

https://github.com/apache/guacamole-server/blob/382d72a26a04008aa936680deed00e3a31086b1e/src/protocols/rdp/channels/cliprdr.c#L356

- return cliprdr->ClientFormatDataResponse(cliprdr, _response);
>
> + UINT result = cliprdr->ClientFormatDataResponse(cliprdr, _response);
> + free(buf);
> + return result;
>
> Your thoughts?
>

I agree that we should manually free() the buffer after
ClientFormatDataResponse() returns. It would be good to also double-check
whether there are any other similar failures to free memory allocated for
an outbound PDU that is handed off to FreeRDP but not actually freed
internally by FreeRDP.

- Mike

Re: [DISCUSS] Scope of 1.3.0 release

[Mike Jumper]

On Sat, Sep 5, 2020 at 10:49 PM Mike Jumper  wrote:

> On Sat, Sep 5, 2020 at 7:50 PM Mike Jumper  wrote:
>
>> On Sat, Sep 5, 2020 at 6:20 PM Nick Couchman  wrote:
>>
>>> ...
>>> > The following are in-progress with some changes already merged:
>>> >
>>> > GUACAMOLE-221 - Parameter prompting within client interface
>>> > GUACAMOLE-857 - Add Docker Image Support for HTTP Header-Based
>>> > Authentication
>>> > GUACAMOLE-1081 - option to convert usernames to all lowercase
>>> > GUACAMOLE-1123 - Standardize on filtered history query for user and
>>> > connection management
>>> >
>>> >
>>> My only question, here, would be on timing of creating the staging/1.3.0
>>> branch - do we try to finish the merge of these into master prior to
>>> doing
>>> the staging change, or does it matter that much?
>>>
>>
>> It shouldn't matter. As long as we consistently merge "staging/1.3.0"
>> back to master, things will be correct and the content of the 1.3.0 release
>> will be safely isolated to only those changes intended for 1.3.0.
>>
>> ...
>>> > Thoughts?
>>> >
>>> >
>>> My only other thought is maybe to add in any that are verified to be
>>> regressions or bugs from 1.1.0 and 1.2.0. At a glance I see the following
>>> potential candidates:
>>>
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1113
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1038
>>> https://issues.apache.org/jira/browse/GUACAMOLE-912
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1140
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1146
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1138
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1129
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1133
>>> https://issues.apache.org/jira/browse/GUACAMOLE-1021
>>>
>>> I'm not saying all of these *have* to be included in the 1.3.0 release,
>>> but
>>> if everyone can jump in and do a little work to verify whether or not
>>> these
>>> are actually valid issues/bugs, and maybe knock out a few here and there,
>>> we could add a few bug fixes to the list.
>>
>>
>> Sure, I'll go through the above momentarily.
>>
>
> Alrighty - I've added the above, as well, with the following exceptions:
>
> GUACAMOLE-1038 - Closed as "Cannot Reproduce". Filtering within the
> "Current Connections" and "All Connections" tabs appears to work just fine.
>
> GUACAMOLE-1113 - Valid, but a full solution will be complex. Half of the
> issue is simple (just handle Right Ctrl), but the other half requires the
> client side keyboard handling to be able to distinguish between Right Alt
> and AltGr, something which has historically been impossible on Mac. I think
> this is worth looking into further when time permits, but not at the
> expense of release timing.
>
> GUACAMOLE-1129 - This is not a bug, but rather a fact of life for the "MS
> Publisher Imagesetter" driver (it sometimes produces huge files). If
> Windows now has a similar and standard driver that directly supports PDF,
> it remains a reasonable feature request. I think this is worth looking into
> further when time permits, but not at the expense of release timing.
>
> GUACAMOLE-1133 - I'm not necessarily against including this, but I also do
> not currently have access to the test Mac (which is at my office). It may
> be possible to obtain access in a week or two, but probably not worth
> holding up the release if I'm the only one that can test. If anyone else
> has the ability to test, I'm happy for this to be in scope.
>
> GUACAMOLE-1138 - Closed as "Cannot Reproduce". Windows 2016 connections
> appear to work perfectly, with the exception of known bugs in certain
> versions of FreeRDP and ABI incompatibilities between FreeRDP versions
> necessitating a rebuild.
>
> GUACAMOLE-1140 - This may well be valid, but looks like it will be complex
> to investigate and (if valid) address. There may be a race condition
> involved. It's worth pursuing, but I would lean toward excluding this from
> 1.3.0 scope.
>

Perhaps also the issue with changes to FreeRDP memory management resulting
in a leak:

https://lists.apache.org/thread.html/r39f830253413b2143438d09533c59e193e78729ef036bf1a1356f33b%40%3Cuser.guacamole.apache.org%3E

- Mike

Re: [DISCUSS] Scope of 1.3.0 release

[Mike Jumper]

On Sat, Sep 5, 2020 at 6:20 PM Nick Couchman  wrote:

> ...
> > The following are in-progress with some changes already merged:
> >
> > GUACAMOLE-221 - Parameter prompting within client interface
> > GUACAMOLE-857 - Add Docker Image Support for HTTP Header-Based
> > Authentication
> > GUACAMOLE-1081 - option to convert usernames to all lowercase
> > GUACAMOLE-1123 - Standardize on filtered history query for user and
> > connection management
> >
> >
> My only question, here, would be on timing of creating the staging/1.3.0
> branch - do we try to finish the merge of these into master prior to doing
> the staging change, or does it matter that much?
>

It shouldn't matter. As long as we consistently merge "staging/1.3.0" back
to master, things will be correct and the content of the 1.3.0 release will
be safely isolated to only those changes intended for 1.3.0.

...
> > Thoughts?
> >
> >
> My only other thought is maybe to add in any that are verified to be
> regressions or bugs from 1.1.0 and 1.2.0. At a glance I see the following
> potential candidates:
>
> https://issues.apache.org/jira/browse/GUACAMOLE-1113
> https://issues.apache.org/jira/browse/GUACAMOLE-1038
> https://issues.apache.org/jira/browse/GUACAMOLE-912
> https://issues.apache.org/jira/browse/GUACAMOLE-1140
> https://issues.apache.org/jira/browse/GUACAMOLE-1146
> https://issues.apache.org/jira/browse/GUACAMOLE-1138
> https://issues.apache.org/jira/browse/GUACAMOLE-1129
> https://issues.apache.org/jira/browse/GUACAMOLE-1133
> https://issues.apache.org/jira/browse/GUACAMOLE-1021
>
> I'm not saying all of these *have* to be included in the 1.3.0 release, but
> if everyone can jump in and do a little work to verify whether or not these
> are actually valid issues/bugs, and maybe knock out a few here and there,
> we could add a few bug fixes to the list.


Sure, I'll go through the above momentarily.

- Mike

[DISCUSS] Scope of 1.3.0 release

[Mike Jumper]

Hello all,

Per release procedures [1], I'd like to get the discussion going on the
1.3.0 release scope, so that maybe we can aim to get back into a quicker
release rhythm (perhaps aiming for mid-September?).

The following have already been completed, merged, etc.:

GUACAMOLE-753 - Add TOTP auth method to start.sh for Docker image
GUACAMOLE-819 - Documented Duo secret key length is incorrect
GUACAMOLE-919 - An I/O error occurred while sending to the backend
GUACAMOLE-942 - Query may fail if all connections disconnect while listing
active connections
GUACAMOLE-949 - Remove unused UNIX_TIME macro
GUACAMOLE-980 - used tomcat-jre8 Docker-Image seems to be deprecated
GUACAMOLE-982 - Typo mistake : incorrect the error log message of RDP
GUACAMOLE-987 - ldap-user-attributes is not set via an env variable
GUACAMOLE-1001 - RADIUS Extension Needs Additional Attributes
GUACAMOLE-1054 - Improve Russian translation
GUACAMOLE-1082 - Add guacamole-auth-cas to docker Script
GUACAMOLE-1103 - Typo mistake : the incorrect comment of a variable for the
RDP setting
GUACAMOLE-1107 - "allowed-languages" property incorrectly documented as
"available-languages"
GUACAMOLE-1110 - Size and security improvements for Docker images
GUACAMOLE-1114 - Problem that the guacamole server doesn't destroy some
thread mutexes
GUACAMOLE-1120 - CAS module causes app.js download errors
GUACAMOLE-1122 - Fail in compile of RDP protocol when SSH is unavailable
GUACAMOLE-1125 - Ctrl+Alt+End(Supr) only working once
GUACAMOLE-1135 - MySQL SSL - Trust Store Paths Expecting URI
GUACAMOLE-1136 - MySQL SSL Client Cert Environment Variables Return Trust
Store
GUACAMOLE-1147 - Add support for additional LDAP properties in Docker
GUACAMOLE-1149 - Login using LDAP fails internally if TOTP is used without
automatic user creation
GUACAMOLE-1150 - Connection group permissions aren't checked correctly
GUACAMOLE-1151 - Add nbproject directory to .gitignore file
GUACAMOLE-1152 - Enabling skip-if-unavailable breaks expired password change
GUACAMOLE-1158 - RDP "disable-copy" flag does not work

The following are in-progress with some changes already merged:

GUACAMOLE-221 - Parameter prompting within client interface
GUACAMOLE-857 - Add Docker Image Support for HTTP Header-Based
Authentication
GUACAMOLE-1081 - option to convert usernames to all lowercase
GUACAMOLE-1123 - Standardize on filtered history query for user and
connection management

The following are in-progress, already marked for 1.3.0, and have
corresponding outstanding PRs:

GUACAMOLE-760 - add timezone info using DB Connection string
GUACAMOLE-793 - CAS Provider returns Group - like LDAP Provider
GUACAMOLE-903 - Improved Chinese internationalization support
GUACAMOLE-1031 - SFTP upload directory ignored
GUACAMOLE-1078 - Add Catalan Language to Guacamole

Thoughts?

- Mike

[1] http://guacamole.apache.org/release-procedures-part1/#discuss-thread

Re: WebP Lossless instead of PNG?

[Mike Jumper]

On Fri, Aug 7, 2020, 06:30 Andras Sali  wrote:

> Hi Nick,
>
> Yes, thanks, I am aware that guacd already can use WebP if it's available.
> However if I see correctly, it is only used for **lossy compression** - the
> lossless flag is set to 0 (
>
> https://github.com/apache/guacamole-server/blob/master/src/common/surface.c#L1794
> ).
>
> WebP also supports lossless compression using a separate algorithm (
>
> https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification
> ),
> which would be a direct alternative for PNG updates. In the benchmark I
> linked in my previous email, lossless webP encoding can be faster and more
> efficient for many types of images than PNG (question if this is also the
> case for screen updates).
>
> So I understand that guacd already intelligently switches between PNG /
> WebP Lossy depending on different metrics, however my question is regarding
> using WebP Lossless instead of PNG. In this case the switching would be
> between WebP Lossless and / WebP Lossy depending on the metrics.
>
> Has this already been tried and discarded for some reason?
>

Yes, waaayyy back when WebP support was first finding its way into
Guacamole, prior to the project moving to the ASF. There were mixed results
in our own testing, showing that WebP would often compress worse and slower
than PNG, resulting in increased latency and bandwidth usage.

There was also a mysterious issue where libwebp would effectively ignore
the lossless quality setting and produce lossy images. By now, this may no
longer be a problem, however I suspect the negative performance
characteristics relative to PNG will still be there.

If you would like to give it a try, by all means see whether things do
improve, however the answer to your question is "yes, lossless WebP was
investigated and ultimately rejected due to poor performance
characteristics compared to PNG."

- Mike

Re: TOTP

[Mike Jumper]

Reading through the TOTP extension code, I see the "totp-period" property
value used only to affect code invalidation, with code generation always
using the default value of 30:

https://github.com/apache/guacamole-client/blob/3c4c81f0b6b9700abccaefcc695058e515b8b20b/extensions/guacamole-auth-totp/src/main/java/org/apache/guacamole/auth/totp/user/UserVerificationService.java#L272-L274
<https://github.com/apache/guacamole-client/blob/33fa0033d20d2d735f858ef0d822a7a219080c5f/extensions/guacamole-auth-totp/src/main/java/org/apache/guacamole/auth/totp/user/UserVerificationService.java#L272-L274>

https://github.com/apache/guacamole-client/blob/3c4c81f0b6b9700abccaefcc695058e515b8b20b/extensions/guacamole-auth-totp/src/main/java/org/apache/guacamole/totp/TOTPGenerator.java#L278-L281

That behavior is likely a bug, however Google Authenticator is currently
documented as ignoring the period value and always assuming 30:

https://github.com/google/google-authenticator/wiki/Key-Uri-Format

Assuming this is still the case, I would expect Google Authenticator to
currently work (as the extension behavior will effectively ignore the
period), and to stop working as soon as the overridden period is taken into
account for code generation (as Google Authenticator would no longer
generate the same codes). I can confirm that Google Authenticator does
appear to assume 30 regardless of the period within the QR code, at least
on Android.

Overall:

1) This is probably a bug and should be fixed.
2) If any of your users will use Google Authenticator, you shouldn't
override the defaults.

- Mike

On Sat, Jul 11, 2020 at 2:08 PM Murat BÜLBÜL <1murat.bul...@gmail.com>
wrote:

> Hi Mike,
>
> I am using MacBook Air. My test phone is Iphone8 plus. I issued QR with
> both GoogleAuthenticator and YAKey. Both generates the same result.
>
> Murat
>
>
> On 11 Jul 2020 Sat at 23:40 Mike Jumper  wrote:
>
> > On Sat, Jul 11, 2020, 10:56 Murat BÜLBÜL <1murat.bul...@gmail.com>
> wrote:
> >
> > > I found the reason and it is interesting. Only 30 seconds is generating
> > > valid code. No successful result for below other cases.
> > >
> > > totp-period: 31 : not working
> > >
> > > totp-period: 60 : not working
> > >
> > > *totp-period: 30 : working*
> > >
> > > totp-period: 20 : not working
> > >
> >
> > Are you sure your authentication device supports periods other than 30?
> >
> > - Mike
> >
> --
> Murat BÜLBÜL
>

Re: TOTP

[Mike Jumper]

On Sat, Jul 11, 2020, 10:56 Murat BÜLBÜL <1murat.bul...@gmail.com> wrote:

> I found the reason and it is interesting. Only 30 seconds is generating
> valid code. No successful result for below other cases.
>
> totp-period: 31 : not working
>
> totp-period: 60 : not working
>
> *totp-period: 30 : working*
>
> totp-period: 20 : not working
>

Are you sure your authentication device supports periods other than 30?

- Mike

Re: What happens after the session page is closed?

[Mike Jumper]

On Sat, Jul 4, 2020 at 8:28 PM Benchu Yao  wrote:

> I request a new token every time I open a new connection session


Why?

and then I want to cancel the token when closing the session page.
>

Why?

- Mike

Re: How to modify the token expiration time

[Mike Jumper]

On Sat, Jul 4, 2020 at 9:26 PM Benchu Yao  wrote:

> If I set api-session-timeout to 0, does it mean that the token will expire
> immediately when the session ends
>

The web application session and the token are essentially the same thing.
They do not expire independently of each other. The token is how the
session is identified, and the session ceases to exist once its token is
invalidated. This is what happens when a user explicitly logs out of
Guacamole or when Guacamole terminates their session due to inactivity.

If you are referring to the remote desktop session, that is an entirely
different beast and has nothing to do with Guacamole's tokens or
Guacamole's sessions. If you want to configure how long a particular remote
desktop server allows sessions to stay alive, you will need to configure
that remote desktop server accordingly.

- Mike

[SECURITY] CVE-2020-9498: Apache Guacamole: Dangling pointer in RDP static virtual channel handling

[Mike Jumper]

CVE-2020-9498: Dangling pointer in RDP static virtual channel handling

Versions affected:
Apache Guacamole 1.1.0 and earlier

Description:
Apache Guacamole 1.1.0 and older may mishandle pointers involved in
processing data received via RDP static virtual channels. If a user
connects to a malicious or compromised RDP server, a series of
specially-crafted PDUs could result in memory corruption, possibly
allowing arbitrary code to be executed with the privileges of the
running guacd process.

Mitigation:
Users of versions of Apache Guacamole 1.1.0 and older that provide
access to untrusted RDP servers should upgrade to 1.2.0.

Credit:
We would like to thank Eyal Itkin (Check Point Research) for reporting
this issue.

[SECURITY] CVE-2020-9497: Apache Guacamole: Improper input validation of RDP static virtual channels

[Mike Jumper]

CVE-2020-9497: Improper input validation of RDP static virtual channels

Versions affected:
Apache Guacamole 1.1.0 and earlier

Description:
Apache Guacamole 1.1.0 and older do not properly validate data
received from RDP servers via static virtual channels. If a user
connects to a malicious or compromised RDP server, specially-crafted
PDUs could result in disclosure of information within the memory of
the guacd process handling the connection.

Mitigation:
Users of versions of Apache Guacamole 1.1.0 and older that provide
access to untrusted RDP servers should upgrade to 1.2.0.

Credit:
We would like to thank the GitHub Security Lab and Eyal Itkin (Check
Point Research) for reporting this issue.

Re: [ANNOUNCE] Apache Guacamole 1.2.0

[Mike Jumper]

All, before this goes too far, please:

* If you encounter any issues with 1.2.0, open a new thread on user@. Don't
just use the release announcement as a help megathread. It will be chaos.

* Don't reply-all to multiple lists; pick a single list and start your
(new) thread there. These messages are going to both user@ and dev@, but
should really just go to one.

I'm replying-all myself here so that all instances of this thread are
notified, but for future questions/responses: please start a new thread and
pick just one list for that thread.

Thanks,

- Mike


On Tue, Jun 30, 2020, 14:22 ivanmarcus  wrote:

> Tom,
>
> Are you still using Ubuntu 20.04? If so, what version of FreeRDP have you
> got running?
>
> Thanks.
>
> On 1/07/2020 1:20 a.m., Daniëls, Tom wrote:
>
> My upgrade on Ubuntu 20.04 was as simple as downloading the client war,
> unzipping and building the server source code, stopping Tomcat and
> replacing the WAR file:
>
>
>
> tar -xzf guacamole-server-1.2.0.tar.gz
>
> cd guacamole-server-1.2.0/
>
> ./configure --with-init-dir=/etc/init.d
>
> make
>
> make install
>
> ldconfig
>
> update-rc.d guacd defaults
>
>
>
> cp guacamole-1.2.0.war /var/lib/tomcat9/webapps/guacamole.war
>
> chown tomcat:tomcat /var/lib/tomcat9/webapps/guacamole.war
>
>
>
> service guacd restart
>
> service tomcat9 restart
>
>
>
> *From:* Peter De Tender  
> *Sent:* dinsdag 30 juni 2020 13:16
> *To:* u...@guacamole.apache.org; annou...@apache.org;
> annou...@guacamole.apache.org; dev@guacamole.apache.org
> *Subject:* Re: [ANNOUNCE] Apache Guacamole 1.2.0
>
>
>
> Hi,
>
> What would be the best practice to upgrade from v1. 1.1 to 1.2?
>
> Thanks Peter
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> --
>
> *From:* Daniëls, Tom 
> *Sent:* Tuesday, June 30, 2020 12:07:18 PM
> *To:* u...@guacamole.apache.org ;
> annou...@apache.org ; annou...@guacamole.apache.org <
> annou...@guacamole.apache.org>; dev@guacamole.apache.org <
> dev@guacamole.apache.org>
> *Subject:* RE: [ANNOUNCE] Apache Guacamole 1.2.0
>
>
>
> Hi Mike,
>
> Looking great! Just deployed and working like a charm 
>
> Grtz
> Tom
>
> -Original Message-
> From: Mike Jumper 
> Sent: dinsdag 30 juni 2020 08:54
> To: annou...@apache.org; annou...@guacamole.apache.org;
> dev@guacamole.apache.org; u...@guacamole.apache.org
> Subject: [ANNOUNCE] Apache Guacamole 1.2.0
>
> The Apache Guacamole community is proud to announce the release of Apache
> Guacamole 1.2.0.
>
> Apache Guacamole is a clientless remote desktop gateway which supports
> standard protocols like VNC, RDP, and SSH. We call it "clientless"
> because no plugins or client software are required; once Guacamole is
> installed on a server, all you need to access your desktops is a web
> browser.
>
> The 1.2.0 release features support for SAML 2.0, Wake-on-LAN, and a new
> interface for easily switching between multiple active connections. The
> general behavior of the login interface has also been improved, as has the
> flexibility of the TOTP support, which may now be used even with user
> accounts that do not yet exist in the database.
>
> A full list of the changes in this release, along with links to downloads
> and updated documentation, can be found in the release
> notes:
>
> http://guacamole.apache.org/releases/1.2.0/
>
> For more information on Apache Guacamole, please see:
>
> http://guacamole.apache.org/
>
> Thanks!
>
> The Apache Guacamole Community
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
> B�CB��
> [��X��ܚX�KK[XZ[
> �\�\�][��X��ܚX�P�XX�[[�K�\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
> �\�\�Z[ �XX�[[�K�\X�K�ܙ�B
>
>
>

[ANNOUNCE] Apache Guacamole 1.2.0

[Mike Jumper]

The Apache Guacamole community is proud to announce the release of
Apache Guacamole 1.2.0.

Apache Guacamole is a clientless remote desktop gateway which supports
standard protocols like VNC, RDP, and SSH. We call it "clientless"
because no plugins or client software are required; once Guacamole is
installed on a server, all you need to access your desktops is a web
browser.

The 1.2.0 release features support for SAML 2.0, Wake-on-LAN, and a
new interface for easily switching between multiple active
connections. The general behavior of the login interface has also been
improved, as has the flexibility of the TOTP support, which may now be
used even with user accounts that do not yet exist in the database.

A full list of the changes in this release, along with links to
downloads and updated documentation, can be found in the release
notes:

http://guacamole.apache.org/releases/1.2.0/

For more information on Apache Guacamole, please see:

http://guacamole.apache.org/

Thanks!

The Apache Guacamole Community

[RESULT] [VOTE] Release Apache Guacamole 1.2.0 (RC1)

[Mike Jumper]

On Thu, Jun 25, 2020 at 9:24 PM Mike Jumper  wrote:

> Hello all,
>
> The first release candidate for Apache Guacamole 1.2.0 has been uploaded
> and is ready for VOTE. The draft release notes (along with links to
> artifacts, signatures/checksums, and updated documentation) can be found
> here:
>
> http://guacamole.apache.org/releases/1.2.0/
>
> The git tag for all relevant repositories is "1.2.0-RC1":
>
> https://github.com/apache/guacamole-client/tree/1.2.0-RC1
> https://github.com/apache/guacamole-server/tree/1.2.0-RC1
> https://github.com/apache/guacamole-manual/tree/1.2.0-RC1
>
> Build instructions are included in the manual, which is part of the
> updated documentation referenced above. For convenience:
>
> http://guacamole.apache.org/doc/1.2.0/gug/installing-guacamole.html
>
> Maven artifacts for guacamole-common-js and guacamole-ext can be found in
> the following staging repository (no changes were made to guacamole-common
> this release):
>
> https://repository.apache.org/content/repositories/org apache
> guacamole-1011/
> <https://repository.apache.org/content/repositories/orgapacheguacamole-1011/>
>
> Source and binary distributions (also linked within the release notes):
>
> https://dist.apache.org/repos/dist/dev/guacamole/1.2.0-RC1/
>
> Artifacts have been signed with the "mjum...@apache.org" key listed in:
>
> https://dist.apache.org/repos/dist/dev/guacamole/KEYS
>
> Please review and vote:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>

The VOTE to release RC1 of Apache Guacamole 1.2.0 is now closed. With a
total of +3 binding votes from the PMC, +4 from committers and the
community, and NO -1 votes, the VOTE passes. Overall vote breakdown is as
follows:

+1 Michael Jumper (binding)
+1 Carl Harris (binding)
+1 Tim Worcester
+1 Murat Bülbül
+1 Nick Couchman (binding)
+1 Jim Sullivan
+1 Sean Reid

Thanks to everyone who voted. I'll move forward with promoting the release
candidate to release.

- Mike

Re: Transparent Copy

[Mike Jumper]

On Sat, Jun 27, 2020, 13:19 Murat BÜLBÜL <1murat.bul...@gmail.com> wrote:

> ... Chrome is prompting me when I open any session over https. It works as
> expected. Unfortunately , it does not work over http as you told. Is this
> normal behavior?
>

Yes.

Is there a way to overcome this problem?
>

No. It's not a problem; it's Chrome working exactly as designed.

Chrome does not provide access to the clipboard unless a secure connection
is used. You need to use a secure connection if you want clipboard to work
transparently.

- Mike

Re: Transparent Copy

[Mike Jumper]

On Sat, Jun 27, 2020 at 12:50 PM Murat BÜLBÜL <1murat.bul...@gmail.com>
wrote:

> Dear All,
>
> Although I already set the following option in guacamole config, I can not
> copy or paste transparently on remote sessions. My browser is google chrome
> and it has the latest version.
>

This should already happen by default and isn't a configurable option. Are
you serving things over HTTPS? Except for testing over localhost, Chrome
will block access to the clipboard over connections that are not secure. If
using a secure connection, Chrome will prompt you to grant clipboard access.


> Any experiences recently like this? Affected version is 1.1.0.
>
> enable-clipboard-integration: true


This property doesn't exist. It will not have any effect.

- Mike

[VOTE] Release Apache Guacamole 1.2.0 (RC1)

[Mike Jumper]

Hello all,

The first release candidate for Apache Guacamole 1.2.0 has been uploaded
and is ready for VOTE. The draft release notes (along with links to
artifacts, signatures/checksums, and updated documentation) can be found
here:

http://guacamole.apache.org/releases/1.2.0/

The git tag for all relevant repositories is "1.2.0-RC1":

https://github.com/apache/guacamole-client/tree/1.2.0-RC1
https://github.com/apache/guacamole-server/tree/1.2.0-RC1
https://github.com/apache/guacamole-manual/tree/1.2.0-RC1

Build instructions are included in the manual, which is part of the updated
documentation referenced above. For convenience:

http://guacamole.apache.org/doc/1.2.0/gug/installing-guacamole.html

Maven artifacts for guacamole-common-js and guacamole-ext can be found in
the following staging repository (no changes were made to guacamole-common
this release):

https://repository.apache.org/content/repositories/org apache
guacamole-1011/


Source and binary distributions (also linked within the release notes):

https://dist.apache.org/repos/dist/dev/guacamole/1.2.0-RC1/

Artifacts have been signed with the "mjum...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/guacamole/KEYS

Please review and vote:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Here is my +1.

Thanks,

- Mike

Re: Build failed in Jenkins: guacamole-server-master-ubuntu » ubuntu,rolling #165

[Mike Jumper]

These failures are just due to the new guacenc dependency on libavformat.
I'll update the Jenkins builds to include that dependency and force a
rebuild.

- Mike


On Wed, Jun 24, 2020 at 10:40 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/guacamole-server-master-ubuntu/JENKINS_LABEL_EXPRESSION=ubuntu,UBUNTU_RELEASE=rolling/165/display/redirect?page=changes
> >
>
> Changes:
>
> [sreid] GUACAMOLE-465: added dependency to libavformat as first step to
>
> [sreid] GUACAMOLE-465: resolved issues brought up in PR159 (unneeded
> dynamic mem
>
> [sreid] GUACAMOLE-465: resolved issues brought up in PR159 and added
>
> [mjumper] GUACAMOLE-465: Reformat/reflow comments to match established
> style.
>
> [mjumper] GUACAMOLE-495: Update guacenc mangpage - the MPEG-4 output is no
> longer
>
> [mjumper] GUACAMOLE-495: Add whitespace and reflow as necessary to improve
>
>
> --
> [...truncated 184.45 KB...]
>  [91mlibtool: warning: relinking 'libguacai-client.la'
>  [0mlibtool: install: (cd /build/guacamole-server/src/protocols/rdp;
> /bin/bash "/build/guacamole-server/libtool"  --silent --tag CC
> --mode=relink gcc -Werror -Wall -Iinclude -I../../../src/common
> -I../../../src/common-ssh -I../../../src/libguac -I/usr/include/freerdp2/
> -I/usr/include/winpr2 -g -O2 -module -avoid-version -shared -lpthread
> -lfreerdp2 -lfreerdp-client2 -lwinpr2 -o libguacai-client.la -rpath
> /usr/lib/x86_64-linux-gnu/freerdp2
> channels/audio-input/libguacai_client_la-audio-buffer.lo
> plugins/guacai/libguacai_client_la-guacai-messages.lo
> plugins/guacai/libguacai_client_la-guacai.lo
> plugins/libguacai_client_la-ptr-string.lo ../../../src/common/
> libguac_common.la ../../../src/libguac/libguac.la )
> libtool: install: /usr/bin/install -c .libs/libguacai-client.soT
> /usr/lib/x86_64-linux-gnu/freerdp2/libguacai-client.so
> libtool: install: /usr/bin/install -c .libs/libguacai-client.lai
> /usr/lib/x86_64-linux-gnu/freerdp2/libguacai-client.la
> libtool: finish:
> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin"
> ldconfig -n /usr/lib/x86_64-linux-gnu/freerdp2
> --
> Libraries have been installed in:
>/usr/lib/x86_64-linux-gnu/freerdp2
>
> If you ever happen to want to link against installed libraries
> in a given directory, LIBDIR, you must either use libtool, and
> specify the full pathname of the library, or use the '-LLIBDIR'
> flag during linking and do at least one of the following:
>- add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
>  during execution
>- add LIBDIR to the 'LD_RUN_PATH' environment variable
>  during linking
>- use the '-Wl,-rpath -Wl,LIBDIR' linker flag
>- have your system administrator add LIBDIR to '/etc/ld.so.conf'
>
> See any operating system documentation about shared libraries for
> more information, such as the ld(1) and ld.so(8) manual pages.
> --
> make[4]: Leaving directory '/build/guacamole-server/src/protocols/rdp'
> make[3]: Leaving directory '/build/guacamole-server/src/protocols/rdp'
> Making install in tests
> make[3]: Entering directory
> '/build/guacamole-server/src/protocols/rdp/tests'
> make[4]: Entering directory
> '/build/guacamole-server/src/protocols/rdp/tests'
> make[4]: Nothing to be done for 'install-exec-am'.
> make[4]: Nothing to be done for 'install-data-am'.
> make[4]: Leaving directory
> '/build/guacamole-server/src/protocols/rdp/tests'
> make[3]: Leaving directory
> '/build/guacamole-server/src/protocols/rdp/tests'
> make[2]: Leaving directory '/build/guacamole-server/src/protocols/rdp'
> make[1]: Leaving directory '/build/guacamole-server/src/protocols/rdp'
> Making install in src/protocols/ssh
> make[1]: Entering directory '/build/guacamole-server/src/protocols/ssh'
> make[2]: Entering directory '/build/guacamole-server/src/protocols/ssh'
>  /usr/bin/mkdir -p '/usr/local/lib'
>  /bin/bash ../../../libtool   --mode=install /usr/bin/install -c
> libguac-client-ssh.la '/usr/local/lib'
>  [91mlibtool: warning: relinking 'libguac-client-ssh.la'
>  [0mlibtool: install: (cd /build/guacamole-server/src/protocols/ssh;
> /bin/bash "/build/guacamole-server/libtool"  --silent --tag CC
> --mode=relink gcc -Werror -Wall -Iinclude -I../../../src/common-ssh
> -I../../../src/libguac -I../../../src/terminal -I/usr/include/pango-1.0
> -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1
> -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16
> -I/usr/include/harfbuzz -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pango-1.0
> -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/cairo
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2
> 

Re: [DISCUSS] Moving forward with RC of 1.2.0

[Mike Jumper]

On Tue, Jun 23, 2020 at 5:03 PM Nick Couchman  wrote:

> On Tue, Jun 23, 2020 at 7:23 PM Mike Jumper  wrote:
>
> > Hello all,
> >
> > It's looking like things for the 1.2.0 release are wrapping up, with only
> > the following issues looking problematic:
> >
> > https://issues.apache.org/jira/browse/GUACAMOLE-300 (LDAP support for
> > "posixGroup")
> >
>
> Regarding this one, I believe the actual code changes have been merged, and
> it's just documentation at this point??  Also, the contributor
> (mlewissmith) responded on it today, so I think we can probably push this
> through.
>

Ah, you're right. Sounds good, then.

- Mike

[DISCUSS] Moving forward with RC of 1.2.0

[Mike Jumper]

Hello all,

It's looking like things for the 1.2.0 release are wrapping up, with only
the following issues looking problematic:

https://issues.apache.org/jira/browse/GUACAMOLE-300 (LDAP support for
"posixGroup")
https://issues.apache.org/jira/browse/GUACAMOLE-793 (CAS support for groups)
https://issues.apache.org/jira/browse/GUACAMOLE-903 (Improved Chinese
translation)

Each of the above is under review and being worked on by their respective
contributors, but I'm not sure how long it will be before everything is
ready for merge. Some of the feedback on the above requires involved
resolutions, possibly with further back-and-forth. Given the size of 1.2.0,
its various fixes to FreeRDP-related regressions, etc. I would like to
suggest bumping these issues to 1.3.0 or later so that we can cut an RC.

Any objection to removing the above three issues from scope of 1.2.0?

Thanks,

- Mike

Re: Build failed in Jenkins: guacamole-server-master #133

[Mike Jumper]

It's because the new header file has not been added to the relevant
Makefile.am, and so is not included in the .tar.gz created by "make dist".
This error wouldn't have occurred if building normally from git, but the
Jenkins build is written to test the creation of the .tar.gz to ensure
release artifacts are correct.

To reproduce the issue, you would need to run "make dist", and then extract
and attempt to build the resulting .tar.gz in some other directory.

- Mike


On Tue, Jun 9, 2020 at 9:53 AM Mike Jumper  wrote:

> I'll take a quick look.
>
> - Mike
>
>
> On Tue, Jun 9, 2020 at 4:08 AM Nick Couchman 
> wrote:
>
>> Hmmmthis is odd.  I did verify everything compiled before calling it
>> good on these changes, and I've recompiled just now to make sure, and
>> verified that the same include is in the code I'm compiling.  Not sure why
>> this one is failing??
>>
>> -Nick
>>
>> On Tue, Jun 9, 2020 at 4:27 AM Apache Jenkins Server <
>> jenk...@builds.apache.org> wrote:
>>
>> > See <
>> >
>> https://builds.apache.org/job/guacamole-server-master/133/display/redirect?page=changes
>> > >
>> >
>> > Changes:
>> >
>> > [vnick] GUACAMOLE-513: Implement settings and code for Wake-on-LAN
>> support.
>> >
>> > [vnick] GUACAMOLE-513: Add debug logging for sending WoL.
>> >
>> > [vnick] GUACAMOLE-513: Move sleep to protocol implementations; update
>> > comments
>> >
>> > [vnick] GUACAMOLE-513: Make packet size a constant.
>> >
>> > [vnick] GUACAMOLE-513: Support determining IPv4 or IPv6.
>> >
>> > [vnick] GUACAMOLE-513: Adjust names of constants and fix style.
>> >
>> > [vnick] GUACAMOLE-513: Implement defaults header for protocol constants.
>> >
>> > [vnick] GUACAMOLE-513: Properly close WOL socket.
>> >
>> >
>> > --
>> > [...truncated 198.30 KB...]
>> >Library status:
>> >
>> >  freerdp2  yes
>> >  pango ... yes
>> >  libavcodec .. yes
>> >  libavutil ... yes
>> >  libssh2 . yes
>> >  libssl .. yes
>> >  libswscale .. yes
>> >  libtelnet ... yes
>> >  libVNCServer  yes
>> >  libvorbis ... yes
>> >  libpulse  yes
>> >  libwebsockets ... yes
>> >  libwebp . yes
>> >  wsock32 . no
>> >
>> >Protocol support:
>> >
>> >   Kubernetes  yes
>> >   RDP ... yes
>> >   SSH ... yes
>> >   Telnet  yes
>> >   VNC ... yes
>> >
>> >Services / tools:
>> >
>> >   guacd .. yes
>> >   guacenc  yes
>> >   guaclog  yes
>> >
>> >FreeRDP plugins: /usr/lib64/freerdp2
>> >Init scripts: no
>> >Systemd units: no
>> >
>> > Type "make" to compile guacamole-server.
>> >
>> >  [91m+ make
>> >  [0mmake  all-recursive
>> > make[1]: Entering directory
>> > `/build/guacamole-server/guacamole-server-1.2.0'
>> > Making all in src/libguac
>> > make[2]: Entering directory
>> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac'
>> > Making all in .
>> > make[3]: Entering directory
>> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac'
>> >   CC   libguac_la-audio.lo
>> >   CC   libguac_la-client.lo
>> >   CC   libguac_la-encode-jpeg.lo
>> >   CC   libguac_la-encode-png.lo
>> >   CC   libguac_la-error.lo
>> >   CC   libguac_la-hash.lo
>> >   CC   libguac_la-id.lo
>> >   CC   libguac_la-palette.lo
>> >   CC   libguac_la-parser.lo
>> >   CC   libguac_la-pool.lo
>> >   CC   libguac_la-protocol.lo
>> >   CC   libguac_la-raw_encoder.lo
>> >   CC   libguac_la-socket.lo
>> >   CC   libguac_la-socket-broadcast.lo
>> >   CC   libguac_la-socket-fd.lo
>> >   CC   libguac_la-socket-nest.lo
>> >   CC   libguac_la-socket-tee.lo
>> >   CC   libguac_la-string.lo
>> >   CC   libguac_la-timestamp.lo
>> >   CC   libguac_la-unicode.lo
>> >   CC   libguac_la-user.lo
>&g

Re: Build failed in Jenkins: guacamole-server-master #133

[Mike Jumper]

I'll take a quick look.

- Mike


On Tue, Jun 9, 2020 at 4:08 AM Nick Couchman 
wrote:

> Hmmmthis is odd.  I did verify everything compiled before calling it
> good on these changes, and I've recompiled just now to make sure, and
> verified that the same include is in the code I'm compiling.  Not sure why
> this one is failing??
>
> -Nick
>
> On Tue, Jun 9, 2020 at 4:27 AM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See <
> >
> https://builds.apache.org/job/guacamole-server-master/133/display/redirect?page=changes
> > >
> >
> > Changes:
> >
> > [vnick] GUACAMOLE-513: Implement settings and code for Wake-on-LAN
> support.
> >
> > [vnick] GUACAMOLE-513: Add debug logging for sending WoL.
> >
> > [vnick] GUACAMOLE-513: Move sleep to protocol implementations; update
> > comments
> >
> > [vnick] GUACAMOLE-513: Make packet size a constant.
> >
> > [vnick] GUACAMOLE-513: Support determining IPv4 or IPv6.
> >
> > [vnick] GUACAMOLE-513: Adjust names of constants and fix style.
> >
> > [vnick] GUACAMOLE-513: Implement defaults header for protocol constants.
> >
> > [vnick] GUACAMOLE-513: Properly close WOL socket.
> >
> >
> > --
> > [...truncated 198.30 KB...]
> >Library status:
> >
> >  freerdp2  yes
> >  pango ... yes
> >  libavcodec .. yes
> >  libavutil ... yes
> >  libssh2 . yes
> >  libssl .. yes
> >  libswscale .. yes
> >  libtelnet ... yes
> >  libVNCServer  yes
> >  libvorbis ... yes
> >  libpulse  yes
> >  libwebsockets ... yes
> >  libwebp . yes
> >  wsock32 . no
> >
> >Protocol support:
> >
> >   Kubernetes  yes
> >   RDP ... yes
> >   SSH ... yes
> >   Telnet  yes
> >   VNC ... yes
> >
> >Services / tools:
> >
> >   guacd .. yes
> >   guacenc  yes
> >   guaclog  yes
> >
> >FreeRDP plugins: /usr/lib64/freerdp2
> >Init scripts: no
> >Systemd units: no
> >
> > Type "make" to compile guacamole-server.
> >
> >  [91m+ make
> >  [0mmake  all-recursive
> > make[1]: Entering directory
> > `/build/guacamole-server/guacamole-server-1.2.0'
> > Making all in src/libguac
> > make[2]: Entering directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac'
> > Making all in .
> > make[3]: Entering directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac'
> >   CC   libguac_la-audio.lo
> >   CC   libguac_la-client.lo
> >   CC   libguac_la-encode-jpeg.lo
> >   CC   libguac_la-encode-png.lo
> >   CC   libguac_la-error.lo
> >   CC   libguac_la-hash.lo
> >   CC   libguac_la-id.lo
> >   CC   libguac_la-palette.lo
> >   CC   libguac_la-parser.lo
> >   CC   libguac_la-pool.lo
> >   CC   libguac_la-protocol.lo
> >   CC   libguac_la-raw_encoder.lo
> >   CC   libguac_la-socket.lo
> >   CC   libguac_la-socket-broadcast.lo
> >   CC   libguac_la-socket-fd.lo
> >   CC   libguac_la-socket-nest.lo
> >   CC   libguac_la-socket-tee.lo
> >   CC   libguac_la-string.lo
> >   CC   libguac_la-timestamp.lo
> >   CC   libguac_la-unicode.lo
> >   CC   libguac_la-user.lo
> >   CC   libguac_la-user-handlers.lo
> >   CC   libguac_la-user-handshake.lo
> >   CC   libguac_la-wait-fd.lo
> >   CC   libguac_la-wol.lo
> >   CC   libguac_la-encode-webp.lo
> >   CC   libguac_la-socket-ssl.lo
> >   CCLD libguac.la
> > make[3]: Leaving directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac'
> > Making all in tests
> > make[3]: Entering directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac/tests'
> > make[3]: Nothing to be done for `all'.
> > make[3]: Leaving directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac/tests'
> > make[2]: Leaving directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/libguac'
> > Making all in src/common
> > make[2]: Entering directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/common'
> > Making all in .
> > make[3]: Entering directory
> > `/build/guacamole-server/guacamole-server-1.2.0/src/common'
> >   CC   libguac_common_la-io.lo
> >   CC   libguac_common_la-blank_cursor.lo
> >   CC   libguac_common_la-clipboard.lo
> >   CC   libguac_common_la-cursor.lo
> >   CC   libguac_common_la-display.lo
> >   CC   libguac_common_la-dot_cursor.lo
> >   CC   libguac_common_la-ibar_cursor.lo
> >   CC   libguac_common_la-iconv.lo
> >   CC   libguac_common_la-json.lo
> >   CC   libguac_common_la-list.lo
> >   CC   libguac_common_la-pointer_cursor.lo
> >   CC   libguac_common_la-recording.lo
> >   CC   libguac_common_la-rect.lo
> >   CC   libguac_common_la-string.lo
> >   CC   libguac_common_la-surface.lo
> >   

Re: api endpoint to update password for guacadmin user

[Mike Jumper]

There is no endpoint specific to the guacadmin user. The guacadmin user is
not a special case and is handled like any other user (based purely on
granted permissions).

The reason permission is denied in the case described is that the user
changing the password is the same as the whose password is being changed.
If a user is changing their own password, they must do so using the
endpoint which validates that they know their current password. The
endpoint for directly setting the password of a user (without knowledge of
their current password) can only be used for users that are not the current
user.

- Mike


On Mon, Jun 8, 2020, 07:15 Pablo Escobar Lopez 
wrote:

> Hi,
>
> Some time ago I wrote an ansible module
>  to manage guacamole users
> and connections using the guacamole api.
>
> While developing it I realized that "guacamole webui >> settings >> users
> >> edit user" uses this api endpoint
> <
> https://github.com/scicore-unibas-ch/ansible-modules-guacamole/blob/master/plugins/modules/guacamole_user.py#L183
> >
>  which
> allows me to modify any of these settings
> <
> https://github.com/scicore-unibas-ch/ansible-modules-guacamole/blob/master/plugins/modules/guacamole_user.py#L215-L231
> >
> for
> any guacamole user excepting for the default admin user "guacadmin". When I
> try to edit the guacadmin user to update the password I get a 403
>
> To update the password for guacadmin user I have to go to "webui >>
> settings >> preferences >> change password" which uses a different api
> endpoint
> "{url}/api/session/data/postgresql/users/guacadmin/password?token={token}"
> which expects a json payload in
> format '{"oldPassword":"guacadmin","newPassword":"password"}'
>
> I am going to add support to my ansible module to be able to update the
> password for the guacadmin user using this specific api endpoint but before
> doing it I thought that would ask here what's the motivation to have a
> different api endpoint to update the password for guacadmin user? is this
> always going to be like this or do you plan to update the api so it also
> allows to update the guacadmin user using the same api endpoint as for any
> other user?
>
> thanks in advance for your advice.
>
> regards,
> Pablo.
>
> --
> Pablo Escobar López
> Linux/HPC systems engineer
> sciCORE, University of Basel
> SIB Swiss Institute of Bioinformatics
>

Re: Regarding h.264 video streams from guacd

[Mike Jumper]

On Sat, May 23, 2020, 05:24 Sean Reid  wrote:

> Carrying on from the discussion that happened in the user@ mailing list
> called "Hardware Acceleration Support", it was discussed that a POC that
> allowed guacd to stream h.264 video using the video instruction in the
> guacamole protocol may be interesting.
>
> I've been thinking about this since that discussion and have started
> thinking about how I'd go about producing the POC, but my experience in
> guacamole-server thus far has been scoped pretty tightly to guacenc and so
> I'm having a hard time finding where to look in libguac and guacd's source.
>
> My initial thought was that a good entry point for understanding the
> process guacd uses now and potentially making initial changes I may want to
> make would be where guacd receives display protocol data from VNC/RDP/etc
> and unmarshalls the display images, but before they are encoded for sending
> to the guacamole-client. Can anyone point me to that area of the code or
> tell me if they think there might be a better place to start looking?
>

I think you're on the right track. I would suggest, in particular:

* The parts of the internal, common surface implementation that decide
whether to use a lossy compression method. For example:
https://github.com/apache/guacamole-server/blob/029563a4b9b61150e6945fb48da3dd5dd7fde4f4/src/common/surface.c#L539-L569
* The parts of libguac that deal with encoding WebP, as that is an optional
feature supported at the core library level. Support for H.264 (and
possibly other codecs) would likely need a similar approach, where the API
is constant but may behave differently depending on what has been compiled
in. For example:
https://github.com/apache/guacamole-server/blob/029563a4b9b61150e6945fb48da3dd5dd7fde4f4/src/libguac/client.c#L636-L650

I would imagine that an implementation of this would involve some support
at the libguac level, just as support for PNG/JPEG/WebP is provided by
libguac, and some additional automatic logic within the common surface
implementation to decide whether to stream H.264 rather than encode things
as PNG/JPEG/WebP.

There will be some additional complexity there, as Guacamole video streams
render to an entire layer, not a rectangle within an existing layer. A
nested layer would need to be created wherever a video stream should be
rendered, and that layer would need to be removed (and baked in with a
traditional image draw operation) whenever switching back to non-video
rendering, as the "video" instruction intentionally does not guarantee that
the result of rendering the streamed video will actually be part of the
image content of the layer (it is not guaranteed to be available for copy
operations, etc.).

- Mike

Re: StandardTokens

[Mike Jumper]

On Thu, May 14, 2020 at 2:59 AM Murat BÜLBÜL <1murat.bul...@gmail.com>
wrote:

> Hi Mike,
>
> I already requested subscription to mail list.
>

Perhaps you did not confirm your subscription? You are still hitting the
moderation queue.

Son, you mean that customization and defining new alias tokens is
> impossible, isn't it?
>

The StandardTokens class has nothing to do with defining new parameter
tokens. It was simply a source of several default tokens. Those same tokens
are still there. They are now supplied automatically via connect() as
described in the documentation.

- Mike

Re: StandardTokens

[Mike Jumper]

On Thu, May 14, 2020 at 2:24 AM Murat BÜLBÜL <1murat.bul...@gmail.com>
wrote:

> Dear all,
>

Beware that your email initially hit the moderation queue. I've manually
approved it, and manually CC'd you so that you will receive this response,
but you will need to subscribe to the list to post further or receive the
responses of others.

As i see, StandartTokens class is deprecated in 1.1.0 version. Is there any
> way to use StandartTokens class since I have some alias tokens there like
> Record File Name path and Record file name, etc.
>

The StandardTokens class is deprecated because the class is no longer
needed. From the deprecation note within the documentation for this class
at
http://guacamole.apache.org/doc/guacamole-ext/org/apache/guacamole/token/StandardTokens.html
:

"Standard tokens are now supplied by default to the connect() functions of
connections and connection groups. Manually generating the standard tokens
is not necessary."

You do not need to use this class. The functionality it provided is now
automatic.

- Mike

Re: Races in guacd

[Mike Jumper]

On Tue, May 12, 2020 at 5:31 AM Grigory Trenin  wrote:

> Hi Guacamole developers,
>
> I think I have found a couple of races in gaucd (this is aside from
> GUACAMOLE-1053, which is a third one).
>
> 1) libguac starts a user input thread and detaches from it. The problem is
> that it does not wait for this thread to terminate before calling
> client->free_handler. Doing so opens the road to race conditions if
> client->free_handler is freeing a resource (eg: mutex) that is used in user
> input handlers.
>

When the client is being cleaned up, ensuring that the input thread (the
thread handling inbound Guacamole instructions) is terminated first makes
sense. I think this is worth doing, and then documenting the guarantee that
no other handlers will be in-progress or invoked after the free_handler is
invoked.


> 2) You are using fork() in a multithreaded program. If you are doing that,
> a caution must be taken not to call fork() at the same time when another
> thread is calling any libc function that uses locks, such as malloc() or
> free(). Better to avoid such situation at all, eg: call fork() as early as
> possible (when no threads are created yet), and then create all required
> threads (but it requires some architecture changes to guacd).
>

Do you have a specific example of a place where such a race is possible
within guacd?

I recall considering this when screen sharing support was being developed,
and attempting to take this into account when using fork() alongside code
that needed to be threaded, but I may simply be wrong.

- Mike

Re: Send keyboard scancodes instead of characters for RDP connections

[Mike Jumper]

On Sat, May 9, 2020, 12:36 gabriel sztejnworcel 
wrote:

> Thanks for you answer Mike!
>
> What if the server has 2 layouts, for example French (azerty) and Hebrew,
> and the user wants to switch between them during the session? Won't that be
> a problem?
>

Yes. The user should switch layouts on the client side, not within the
server.

If the client can send the key scancodes, won't that solve the problem in
> this scenario?


It would shift the location of layout switching to the server. Doing so
would make things behave the way you specifically want, but may be a step
backwards from the goal of making things as seamless as possible.

Is it technically possible to implement this?


With recent changes to JavaScript key events, possibly, but not across the
board. Not all input devices have scancodes.

The biggest concerns here would be:

1) Loss of seamlessness. Keyboard behavior *should* be dictated by the
behavior of the client's keyboard.

2) Loss of compatibility. Not all platforms will have scancodes, let alone
ones that correspond to Windows.

3) Loss of functionality. Not all keys produce key events, and some keys do
so only unreliably.

It may be reasonable to provide the option at the connection level, to
allow the administrator to choose whether to favor the client-side layout
(and translate to a known server layout) or the server-side layout (and
entirely ignore client-side key identity).

Philosophically, I don't like it. If such a change is implemented, I would
be concerned that it might be used as a crutch on the admin side (to avoid
having to think about what layout is selected), to the detriment of users.

It is something that may be necessary in the case that keyboard layout MUST
be changeable within the remote desktop. Direct connections to VM consoles
come to mind.

Even if implemented, I don't think that is the solution you should look
toward. It would be better to allow your users to transparently use their
keyboard as it is locally configured, without having them worry about
manually configuring things again within the remote desktop. This is the
way things are already designed.

- Mike

Re: Send keyboard scancodes instead of characters for RDP connections

[Mike Jumper]

On Thu, May 7, 2020 at 2:09 PM gabriel sztejnworcel 
wrote:

> Hi,
>
> Is it technically possible to modify the Guacamole client and server to
> work with keyboard scancodes instead actual characters for RDP connections?
> The way it works today, you have to specify the keyboard layout of the RDP
> server you are connecting to, which is a problem if (for example) there are
> several layouts on the server and you switch between them.
>

The intent of the design is that the user will switch keyboard layouts on
the client side if they need to use a different keyboard layout, and that
the user should not concern themselves with the keyboard configuration
within the remote desktop (which would be purely the administrator's
concern). So long as the server layout is correctly configured at the
connection level, users should be able to choose whichever local layout
they desire and have things work as expected.

- Mike

Re: Tech Deep Dive

[Mike Jumper]

Hi Chris,

I like this idea. I can't say I know much in the area of webinar creation,
but I'm an expert on the Guacamole side and would be interested in
participating.

Thanks,

- Mike

On Sun, Apr 12, 2020 at 7:47 AM Chris Misztur  wrote:

> Guac Team:
>
> I see there has been a lot of discussion around the extensibility of
> Guacamole.  I would love to participate in a deep dive webinar that walks
> through the structure of the project, the protocol itself, and host to
> server to client example implementation.
>
> I am willing to sponsor a part of the team's time.
>
> Chris
>

FreeRDP is now bumping version of master to 3.0.0

[Mike Jumper]

FYI - our nightly verify-things-still-compile-against-FreeRDP-master build
is now failing due to the library version having been bumped to 3.0.0 on
master:

https://builds.apache.org/job/guacamole-server-master-freerdp/FREERDP_BRANCH=master,JENKINS_LABEL_EXPRESSION=ubuntu/123/consoleFull

This appears to be due to FreeRDP 2.0.0 being officially released as of
2020-04-09. A new "stable-2.0" branch has also been created.

The headers, etc. are now also moved to a different directory (freerdp3
rather than freerdp2). I haven't tried making the needed changes to allow
the build to continue. It may be that things still build as expected.

Re: The VNC console response slowly or get stuck after opening more than five console windows

[Mike Jumper]

On Wed, Apr 8, 2020, 12:36 Nick Couchman  wrote:

> On Wed, Apr 8, 2020 at 3:23 PM Wenhu Liu (wenhuliu)
>  wrote:
>
> > Hi, guacamole team，
> >
> > I Integrated Guacamole into an existing application ,but once I open more
> > than five console windows at the same time, the console get stuck or get
> an
> > error “HTTP tunnel request failed: Connection to guacd timed out”. The
> > guacamole web client has no this issue。
> >
> > I have no idea about this。Do you kown why？
> >
> >
> I would examine:
> - Resources on the Guacamole server and make sure that the server is not
> starved for resources
> - Bandwidth between your client and the server and make sure that you are
> not over-utilizing the circuit
> - Bandwidth between the Guacamole server and the remote servers and make
> sure there is not a bandwidth constraint on that side.
>

This might be due to HTTP vs. WebSocket and browsers enforcing a limit on
the maximum number of concurrent HTTP connections to a particular domain.

- Mike

Re: Missing Settings menu in Guacamole UI

[Mike Jumper]

On Fri, Apr 3, 2020, 19:48 Phill Edwards  wrote:

> I've just got Guacamole up and running. From YouTube videos and screenshots
> I've seen I should have a settings menu where I can do things like edit
> "Connections", "Users" and "Groups". But my Settings menu only has "Active
> Sessions" and Preferences".
>
> How do I get the full menu? I want the full menu because I need to edit
> some RDP connection settings and I don't know what the parameter names are
> to edit the user-mapping.xml file directly.
>

You need to set up a backend database, like MySQL or PostgreSQL, and then
log in with an administrative account:

https://guacamole.apache.org/doc/gug/jdbc-auth.html

See:

https://guacamole.apache.org/doc/gug/administration.html

The other mechanisms, like the built-in user-mapping.xml, are read-only and
thus will not produce that interface.

As for the parameter names, all parameters and their names are documented
here:

https://guacamole.apache.org/doc/gug/configuring-guacamole.html#connection-configuration

- Mike

Re: Getting shared link using Rest APIs

[Mike Jumper]

On Wed, Feb 26, 2020 at 7:11 PM Abhinav Jain  wrote:

> Hi all,
>
>
Please do not post the same thread to multiple lists:

https://www.apache.org/dev/contrib-email-tips#rightlist

As you are not subscribed to either list, the user@ list automatically
rejected your post and the dev@ list sent it to the moderation queue, so
ultimately only one thread was created after all. Since you're not
subscribed, I'm explicitly CC'ing you on this message so you will see this,
but *beware that you will need to subscribe to the relevant mailing list
(in this case dev@) to receive responses to your post*.

I’m trying to get the shared link using Rest APIs. I can get it using UI
> but while doing the same thing via POSTMAN I’m getting the following error.
>
> {
> "message": "No such tunnel.",
> "translatableMessage": {
> "key": "No such tunnel.",
> "variables": null
> },
> "statusCode": null,
> "expected": null,
> "type": "NOT_FOUND"
> }
>
>
> I’m using the following api call
>
>
> https://IP/api/session/tunnels/UID/activeConnection/sharingCredentials/3?token=
>
> It seems I need to click on the connection via UI to make it active then
> only I can generate the UID. Is there any way I can activate the connection
> using Rest APIs.
>

It's not a matter of some sort of activation; you simply can't share a
connection that isn't being used.

If you want to provide access to a single connection for a particular user,
what you need is to grant that user access to that connection, not attempt
to generate sharing credentials. Without some user already using the
connection in question, there is nothing to be shared.

- Mike

Re: Beginner's question

[Mike Jumper]

On Sat, Feb 22, 2020, 15:35 Mikael Hansson 
wrote:

> Thanks for the pointers - and sorry for missing the build instructions: It
> was way easier to do it the right way.
>
> I’ve tested my keymap and it seems to do what it should. Pull requests
> have been created for the necessary changes to guacamole-server and
> guacamole-client.
>

Excellent. Thanks!

- Mike

Re: Beginner's question

[Mike Jumper]

On Fri, Feb 21, 2020 at 2:40 AM Mikael Hansson 
wrote:

> Hi,
> I’ve created a new RDP keymap for Guacamole as per
> https://issues.apache.org/jira/browse/GUACAMOLE-121?focusedCommentId=15721121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15721121
> .
> However when I build the Guacamole server from these sources and install
> it, I don’t see the new keymap as a selectable option in the connection
> settings. Obviously I’ve missed some step here.
>
> What I’ve done:
> - I’ve cloned the Guacamole server repository from Github.
> - I’ve copied a keymap file similar to what I needed, and updated its
> contents.
> - I’ve copied the configure script and a bunch of Makefile.* files to
> their respective directories in my instance of the cloned repo from the
> official guacamole-server-1.1.0.tgz archive, in response to error messages
> when running the configure script.
>

You shouldn't do this - who knows whether what you copied is the same as
what would be generated from current git. Use "autoreconf -fi" to generate
the configure script and Makefile-generation input. See:

http://guacamole.apache.org/doc/gug/installing-guacamole.html#guacamole-server-build-process

- I’ve updated Makefile.am and Makefile.in, in src/protocols/rdp, to in
> addition to the existing keymap files also know about the new one.
>

You only need to update the relevant Makefile.am.

- I then ran make clean, ./configure
> --with-systemd-dir=/etc/systemd/system, make, and sudo make install
> sequentially.
> - Finally I ran systemctl daemon-reload && systemctl restart guacd &&
> systemctl restart tomcat9, and cleared my browser cache before attempting
> to change keymaps.
> - /usr/local/sbin/guacd has a timestamp that makes sense, so it has been
> updated by make install.
>
> My guess is that there’s a smarter way of generating the configure script
> and Makefile.* files, and that the build system for some reason still is
> unaware of the new keymap file, but I have no idea what I’m looking for.
>

There is (see above), but this is not going to result in the keymap being
listed as a choice within the web interface. The choices within the web
interface are driven by the contents of JSON files which describe the
parameters of each protocol. For example, the RDP keymaps are defined here:

https://github.com/apache/guacamole-client/blob/bc83918fb3df60a35279741a3dbe90a6092990da/guacamole-ext/src/main/resources/org/apache/guacamole/protocols/rdp.json#L89-L110

The values are automatically canonicalized to translation keys, which
produce the human-readable values you see in the interface:

https://github.com/apache/guacamole-client/blob/bc83918fb3df60a35279741a3dbe90a6092990da/guacamole/src/main/webapp/translations/en.json#L538-L553

Please be sure to also consider contributing your keymap. Contributions are
welcome, we can always use more keymaps, and we can help through the
additional changes needed for your new keymap to be properly listed.

- Mike

Re: Next Release (1.2.0 ?) Scope

[Mike Jumper]

Looks like we have general consensus on scope here. I've rechecked the
changes merged to master and that those JIRA issues are properly tagged.
Current scope stands at:

https://issues.apache.org/jira/issues/?jql=Project%20%3D%20GUACAMOLE%20AND%20fixVersion%20%3D%201.2.0%20ORDER%20BY%20Status%20ASC%2C%20Watchers%2C%20Votes%2C%20Priority

I'll move forward with creating the "staging/1.2.0" branches and we'll be
underway.

- Mike


On Tue, Feb 11, 2020 at 2:26 PM Nick Couchman  wrote:

> Okay, I've tagged all of the issues for the 1.2.0 release, so we have a
> good idea of what needs to be knocked out to get the 1.2.0 release done
> :-).
>
> -Nick
>
> On Tue, Feb 11, 2020 at 9:43 AM Nick Couchman  wrote:
>
> > Thanks for fixing those issues up, Mike.
> >
> > I'm totally good being flexible with the 1.2.0 release and factoring in
> > some of the bug fixes and minor tweaks coming off the 1.1.0 release.  My
> > biggest goal is to keep the momentum up and release 1.2.0 sometime prior
> to
> > January 2021 :-D.  In all seriousness, though, I'd like to limit the
> > feature creep on this release so that we don't end up with any huge
> > blockers and can turn it around a little more quickly.
> >
> > -Nick
> >
> > On Mon, Feb 10, 2020 at 9:48 PM Mike Jumper  wrote:
> >
> >> This list looks good to me, and the scope is fairly minimal. I think we
> >> should plan to be flexible and include bugs that can demonstrated to be
> >> regressions from 1.1.0, even if those bugs are not yet currently known
> and
> >> even if scope is otherwise settled, unless we're so far down the release
> >> or
> >> the bug is so minor that the disruption to the scope outweighs the
> benefit
> >> of a next-release fix.
> >>
> >> In general, from my perspective, a 1.2.0 release should include (at a
> >> minimum):
> >>
> >> * Issues for which code has already been merged (naturally).
> >> * Issues which are known regressions from 1.1.0.
> >> * Issues which are not yet known, are discovered after 1.2.0 is already
> >> underway, but are determined to be regressions from 1.1.0.
> >>
> >> I'm mainly concerned that we'll find something down the line where a
> flag
> >> like freerdp->dont_be_broken became freerdp->DoBeBroken in a later
> >> release,
> >> we didn't notice during the 2.0.0 migration, and things are still being
> >> set
> >> to TRUE. There may well be little surprises in the internal behavior of
> >> FreeRDP that we just won't discover until enough users have pummeled
> 1.1.0
> >> that they happen to pull the right book or lift the right candle and a
> >> secret passageway opens.
> >>
> >> I'm happy to see the issues that Nick listed included, as well. I only
> >> found the following problems:
> >>
> >> * Changes for GUACAMOLE-300 have been merged to master for 1.2.0 but the
> >> issue was not tagged for 1.2.0. I've updated the issue.
> >> * Changes for GUACAMOLE-846 have been merged to master for 1.2.0 but the
> >> issue was not tagged for 1.2.0. I've updated the issue.
> >> * GUACAMOLE-915 was implicitly fixed for 1.1.0 by GUACAMOLE-930 when it
> >> was
> >> identified as a regression. I've updated the issue.
> >>
> >> So, with 300 and 846 being necessarily included, with 915 being removed,
> >> and with a nod toward regression flexibility, I'm good with the list as
> it
> >> stands.
> >>
> >> - Mike
> >>
> >>
> >> On Mon, Feb 3, 2020 at 5:03 PM Nick Couchman  wrote:
> >>
> >> > Thanks for the input, Sean - I definitely agree on trying to maintain
> >> > smaller scopes in general going forward.  I would like to see us be
> >> able to
> >> > actually use the patch version and do some bug fixes or minor
> >> > improvements.  It feels like we've spent the past couple of years
> >> catching
> >> > up on a backlog that includes some pretty big feature enhancements,
> and
> >> it
> >> > has made it difficult to build a momentum for releases.  If we could
> >> get a
> >> > 1.2.0 release done in a small handful of weeks, perhaps we could start
> >> > tightening those scopes down a little more and get a good cadence.
> >> >
> >> > Anyway, if anyone else has input on scope for 1.2.0, please throw that
> >> out
> >> > there, and we can assign remaining issues to 1.2.0 and start work
> >> towards
> >> >

Re: RDP CONNECTION RETURNS THE SAME ERROR CODE FOR ANY ERROR - GUACAMOLE SERVER 1.0.0

[Mike Jumper]

On Wed, Feb 12, 2020 at 11:28 PM Caner ALTUNTAŞ 
wrote:

>
>
> Hello,
>
>
>
> We are having a problem with guacamole server – rdp protocol in our
> company project. ...
>

Caner, please stop resending your original post. Your original post went
out on the dev@ list just fine and received a response:

https://lists.apache.org/thread.html/r319a2548455cd56a69975fbbc9896351889dac25b340e0dba382482a%40%3Cdev.guacamole.apache.org%3E

If you aren't receiving responses, make sure you're subscribed to the list.

- Mike

Re: Next Release (1.2.0 ?) Scope

[Mike Jumper]

This list looks good to me, and the scope is fairly minimal. I think we
should plan to be flexible and include bugs that can demonstrated to be
regressions from 1.1.0, even if those bugs are not yet currently known and
even if scope is otherwise settled, unless we're so far down the release or
the bug is so minor that the disruption to the scope outweighs the benefit
of a next-release fix.

In general, from my perspective, a 1.2.0 release should include (at a
minimum):

* Issues for which code has already been merged (naturally).
* Issues which are known regressions from 1.1.0.
* Issues which are not yet known, are discovered after 1.2.0 is already
underway, but are determined to be regressions from 1.1.0.

I'm mainly concerned that we'll find something down the line where a flag
like freerdp->dont_be_broken became freerdp->DoBeBroken in a later release,
we didn't notice during the 2.0.0 migration, and things are still being set
to TRUE. There may well be little surprises in the internal behavior of
FreeRDP that we just won't discover until enough users have pummeled 1.1.0
that they happen to pull the right book or lift the right candle and a
secret passageway opens.

I'm happy to see the issues that Nick listed included, as well. I only
found the following problems:

* Changes for GUACAMOLE-300 have been merged to master for 1.2.0 but the
issue was not tagged for 1.2.0. I've updated the issue.
* Changes for GUACAMOLE-846 have been merged to master for 1.2.0 but the
issue was not tagged for 1.2.0. I've updated the issue.
* GUACAMOLE-915 was implicitly fixed for 1.1.0 by GUACAMOLE-930 when it was
identified as a regression. I've updated the issue.

So, with 300 and 846 being necessarily included, with 915 being removed,
and with a nod toward regression flexibility, I'm good with the list as it
stands.

- Mike


On Mon, Feb 3, 2020 at 5:03 PM Nick Couchman  wrote:

> Thanks for the input, Sean - I definitely agree on trying to maintain
> smaller scopes in general going forward.  I would like to see us be able to
> actually use the patch version and do some bug fixes or minor
> improvements.  It feels like we've spent the past couple of years catching
> up on a backlog that includes some pretty big feature enhancements, and it
> has made it difficult to build a momentum for releases.  If we could get a
> 1.2.0 release done in a small handful of weeks, perhaps we could start
> tightening those scopes down a little more and get a good cadence.
>
> Anyway, if anyone else has input on scope for 1.2.0, please throw that out
> there, and we can assign remaining issues to 1.2.0 and start work towards
> closing it out.
>
> -Nick
>
> On Mon, Feb 3, 2020 at 19:27 Sean Reid  wrote:
>
> > I don't want to speak much to the scope of this potential release (I
> don't
> > see any issues with the scope you've outlined, especially since most of
> the
> > issues are done or have PRs already), but I do agree with your final
> > sentiments: to limit the scope so that we can release it quickly and move
> > into the next release phase. I tend to prefer a quicker release cadence
> > because it can reduce the changes that changes get unwieldy pretty
> > naturally and it can help avoid too many big changes that can have
> > unintended consequences to stability. I think it can also help minimize
> the
> > time that a user has to wait from the time a bug is discovered to when
> they
> > potentially have a release with a fix.
> >
> > Sean
> >
> > On Sun, Feb 2, 2020 at 4:37 PM Nick Couchman 
> > wrote:
> >
> > > Hey, everyone,
> > > I know I'm always the one pushing things, but I'd like to start
> focusing
> > in
> > > on scope for the 1.2.0 release.  We already have 37 items tagged for
> it,
> > > two of them open, and probably a few more that we could throw into the
> > mix
> > > before we release 1.2.0.
> > >
> > > First, I want to make sure that 1.2.0 is the correct version for this.
> > It
> > > seems appropriate to me - it's more than a minor bug fix release, but
> I'm
> > > not sure there's anything at this point that would push it into a major
> > > release candidate.  But, if anyone has thoughts on that, feel free to
> > > share.
> > >
> > > As far as scope goes, here are the issues currently tagged in that
> > version
> > > in JIRA (
> > > https://issues.apache.org/jira/projects/GUACAMOLE/versions/12345046
> > > ):
> > > 296 (RDP audio input disconnect)
> > > 764 (RDPDR file read/write truncated to 32 bits)
> > > 822 (Balancing group missing client identifier)
> > > 870 (Connection history query fails against SQL Server)
> > > 302 (Refocus relevant in-progress login fields after auth failure)
> > > 381 (Allow clipboard access to be disabled)
> > > 414 (VNC server TLS disconnect)
> > > 514 (Additional VNC authentication methods)
> > > 625 (RDP Spanish LATAM Keyboard support)
> > > 684 (Insufficient credentials take precedence over Invalid credentials)
> > > 723 (Support display of multiple connections in same tab)
> > > 732 

Re: FW: RDP CONNECTION RETURNS THE SAME ERROR CODE FOR ANY ERROR - GUACAMOLE SERVER 1.0.0

[Mike Jumper]

On Thu, Feb 6, 2020 at 11:34 AM Caner ALTUNTAŞ 
wrote:

> ...
>
> Now we are planning to modify this script. We looked up freerdp class
> methods and noticed the method freerdp_get_last_error. It can be useful
> to detect the real error code after freerdp_connect results as false. So,
> according to the error code returning from freerdp_get_last_error we can
> make the script return the most suitable error code.
>

Please feel free to open a JIRA issue and contribute these changes via a PR
when you are ready. I'm not familiar with the full extent of the errors
visible via freerdp_get_last_error(), and you will need to be careful to
map only those errors which make sense to map (not everything should be
exposed to the user), but it should be possible to improve things such that
an appropriate error is forwarded to the user and an appropriate message is
logged on the Guacamole side.

An RDP disconnect due to invalid credentials, etc. is intended to map to a
proper Guacamole error code, though that handling currently only involves
the RDP "disconnect reason" code:

https://github.com/apache/guacamole-server/blob/68a628581866c4d3797cea33d53fa91555cc4383/src/protocols/rdp/error.c

Finally, we would like to ask you that why the script above returns the
> same error code whatever happens? Is there a real reason that it is
> implemented so. We do not want to do something wrong by modifying the
> script and make it effect some other parts of the server. We thought it
> would be better if it is asked to you :)
>

Only because the function freerdp_get_last_error() did not exist in the
versions of FreeRDP that were around at the time the RDP support was
written.

- Mike

[ANNOUNCE] Apache Guacamole 1.1.0

[Mike Jumper]

The Apache Guacamole community is proud to announce the release of Apache
Guacamole 1.1.0.

Apache Guacamole is a clientless remote desktop gateway which supports standard
protocols like VNC, RDP, and SSH. We call it "clientless" because no plugins or
client software are required; once Guacamole is installed on a server, all you
need to access your desktops is a web browser.

The 1.1.0 release features support for dynamic image quality and for
connecting directly to the terminals of Kubernetes pods. Issues with
user group support discovered following the 1.0.0 release have been
fixed, issues with LDAP support have been resolved through migrating
to the Apache Directory API, and issues with RDP support have been
resolved through migrating to FreeRDP 2.0.0.

A full list of the changes in this release, along with links to downloads
and updated documentation, can be found in the release notes:

http://guacamole.apache.org/releases/1.1.0/

For more information on Apache Guacamole, please see:

http://guacamole.apache.org/

Thanks!

The Apache Guacamole Community

[RESULT] [VOTE] Release Apache Guacamole 1.1.0 (RC1)

[Mike Jumper]

On Sun, Jan 26, 2020 at 2:08 PM Mike Jumper  wrote:

> Hello all,
>
> The first release candidate for Apache Guacamole 1.1.0 has been uploaded
> and is ready for VOTE. The draft release notes (along with links to
> artifacts, signatures/checksums, and updated documentation) can be found
> here:
>
> http://guacamole.apache.org/releases/1.1.0/
>
> The git tag for all relevant repositories is "1.1.0-RC1":
>
> https://github.com/apache/guacamole-client/tree/1.1.0-RC1
> https://github.com/apache/guacamole-server/tree/1.1.0-RC1
> https://github.com/apache/guacamole-manual/tree/1.1.0-RC1
>
> Build instructions are included in the manual, which is part of the
> updated documentation referenced above. For convenience:
>
> http://guacamole.apache.org/doc/1.1.0/gug/installing-guacamole.html
>
> Maven artifacts for guacamole-common, guacamole-common-js, and
> guacamole-ext can be found in the following staging repository:
>
> https://repository.apache.org/content/repositories/orgapacheguacamole-1010/
>
> Source and binary distributions (also linked within the release notes):
>
> https://dist.apache.org/repos/dist/dev/guacamole/1.1.0-RC1/
>
> Artifacts have been signed with the "mjum...@apache.org" key listed in:
>
> https://dist.apache.org/repos/dist/dev/guacamole/KEYS
>
> Please review and vote:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>

The VOTE to release RC1 of Apache Guacamole 1.1.0 is now closed. With a
total of +5 binding votes from the PMC, +2 from committers and the
community, and NO -1 votes, the VOTE passes. Overall vote breakdown is as
follows:

+1 Michael Jumper (binding)
+1 Carl Harris (binding)
+1 Sean Reid
+1 Nick Couchman (binding)
+1 Jean-Baptiste Onofré (binding)
+1 Joel Best
+1 James Muehlner (binding)

Thanks to everyone who voted. I'll move forward with promoting the release
candidate to release.

- Mike

[VOTE] Release Apache Guacamole 1.1.0 (RC1)

[Mike Jumper]

Hello all,

The first release candidate for Apache Guacamole 1.1.0 has been uploaded
and is ready for VOTE. The draft release notes (along with links to
artifacts, signatures/checksums, and updated documentation) can be found
here:

http://guacamole.apache.org/releases/1.1.0/

The git tag for all relevant repositories is "1.1.0-RC1":

https://github.com/apache/guacamole-client/tree/1.1.0-RC1
https://github.com/apache/guacamole-server/tree/1.1.0-RC1
https://github.com/apache/guacamole-manual/tree/1.1.0-RC1

Build instructions are included in the manual, which is part of the updated
documentation referenced above. For convenience:

http://guacamole.apache.org/doc/1.1.0/gug/installing-guacamole.html

Maven artifacts for guacamole-common, guacamole-common-js, and
guacamole-ext can be found in the following staging repository:

https://repository.apache.org/content/repositories/orgapacheguacamole-1010/

Source and binary distributions (also linked within the release notes):

https://dist.apache.org/repos/dist/dev/guacamole/1.1.0-RC1/

Artifacts have been signed with the "mjum...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/guacamole/KEYS

Please review and vote:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Here is my +1.

Thanks,

- Mike

Re: Build failed in Jenkins: guacamole-client-master » ubuntu,JDK 1.8 (latest) #190

[Mike Jumper]

On Sat, Jan 25, 2020 at 10:20 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/guacamole-client-master/JENKINS_LABEL_EXPRESSION=ubuntu,jdk=JDK%201.8%20(latest)/190/display/redirect?page=changes
> >
> ...
> [ERROR] unable to create new native thread -> [Help 1]
> ...


My understanding is that Infra is actively working to solve the ongoing
issues with unreliable build slaves. It's looking like these sorts of
failures will be the norm until that happens, though. Something is
routinely eating up all the resources.

- Mike

Recent build failures on nodes H40 and H41

[Mike Jumper]

It looks like the latest batch of build failures from Jenkins are due to
nodes H40 and H41 running out of memory. I've opened a ticket with Infra:

https://issues.apache.org/jira/browse/INFRA-19764

Between when those failures started occurring and when I finished writing
up the ticket, node H40 has been taken offline. It may be that this is
already being looked into.

- Mike

Re: Incoming release candidate (1.1.0-RC1)

[Mike Jumper]

On Wed, Jan 22, 2020 at 6:29 PM Mike Jumper  wrote:

> It looks like things have been ironed out with the FreeRDP 2.0.0-related
> regressions. I've also been doing general regression testing of the webapp
> over the course of the last couple weeks, but haven't encountered anything
> new.
>
> I'm going to do some final tests of LDAP and TOTP tonight. Assuming that
> goes well, I'll tag things, upload the artifacts, and open PRs for the
> draft release notes and docs.
>

Testing complete. I found a pair of regressions within LDAP which should be
fixed and have opened a couple PRs for that:

https://issues.apache.org/jira/browse/GUACAMOLE-936
https://issues.apache.org/jira/browse/GUACAMOLE-937

I think we should be good to go for an RC once the above are knocked out.
Everything else seems to work as expected.

- Mike

Incoming release candidate (1.1.0-RC1)

[Mike Jumper]

It looks like things have been ironed out with the FreeRDP 2.0.0-related
regressions. I've also been doing general regression testing of the webapp
over the course of the last couple weeks, but haven't encountered anything
new.

I'm going to do some final tests of LDAP and TOTP tonight. Assuming that
goes well, I'll tag things, upload the artifacts, and open PRs for the
draft release notes and docs.

- Mike

Re: Build failed in Jenkins: guacamole-server-master-ubuntu » ubuntu,bionic #18

[Mike Jumper]

I've opened an issue with Infra regarding the build failures:

https://issues.apache.org/jira/browse/INFRA-19751

Judging from recent emails on builds@, it's looking like there are
out-of-memory issues on several of the build nodes.

- Mike


On Wed, Jan 22, 2020 at 1:43 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/guacamole-server-master-ubuntu/JENKINS_LABEL_EXPRESSION=ubuntu,UBUNTU_RELEASE=bionic/18/display/redirect
> >
>
> Changes:
>
>
> --
> Failed to access build log
>
> Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to H29
> at
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
> at
> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
> at hudson.remoting.Channel.call(Channel.java:957)
> at hudson.FilePath.act(FilePath.java:1072)
> at hudson.FilePath.act(FilePath.java:1061)
> at hudson.FilePath.toURI(FilePath.java:1206)
> at
> hudson.tasks.MailSender.createFailureMail(MailSender.java:321)
> at hudson.tasks.MailSender.createMail(MailSender.java:181)
> at hudson.tasks.MailSender.run(MailSender.java:111)
> at hudson.tasks.Mailer.perform(Mailer.java:175)
> at hudson.tasks.Mailer.perform(Mailer.java:138)
> at
> hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:741)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
> at hudson.model.Build$BuildExecution.post2(Build.java:186)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
> at hudson.model.Run.execute(Run.java:1840)
> at hudson.matrix.MatrixRun.run(MatrixRun.java:153)
> at
> hudson.model.ResourceController.execute(ResourceController.java:97)
> at hudson.model.Executor.run(Executor.java:429)
> java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method)
> at java.lang.Thread.start(Thread.java:717)
> at
> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at
> hudson.remoting.DelegatingExecutorService.submit(DelegatingExecutorService.java:42)
> at
> hudson.remoting.InterceptingExecutorService.submit(InterceptingExecutorService.java:46)
> at
> hudson.remoting.InterceptingExecutorService.submit(InterceptingExecutorService.java:41)
> at
> org.jenkinsci.remoting.util.AnonymousClassWarnings.check(AnonymousClassWarnings.java:65)
> at
> org.jenkinsci.remoting.util.AnonymousClassWarnings$1.annotateClass(AnonymousClassWarnings.java:121)
> at
> java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1290)
> at
> java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1231)
> at
> java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1294)
> at
> java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1231)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at hudson.remoting.Command.writeTo(Command.java:109)
> at
> hudson.remoting.AbstractSynchronousByteArrayCommandTransport.write(AbstractSynchronousByteArrayCommandTransport.java:43)
> at hudson.remoting.Channel.send(Channel.java:723)
> at hudson.remoting.Request.call(Request.java:160)
> at
> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:286)
> at com.sun.proxy.$Proxy5.fetch3(Unknown Source)
> at
> hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:209)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
> at java.lang.Class.getDeclaredField(Class.java:2068)
> at
> java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1857)
> at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:79)
> at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:506)
> at 

Re: Build failed in Jenkins: guacamole-server-master-docker #38

[Mike Jumper]

Ah, I had this set to oldstable. I'll switch it.

On Tue, Jan 14, 2020, 14:00 Apache Jenkins Server 
wrote:

> See <
> https://builds.apache.org/job/guacamole-server-master-docker/38/display/redirect?page=changes
> >
>
> Changes:
>
> [mjumper] GUACAMOLE-249: Migrate to newer API (partial).
>
> [mjumper] GUACAMOLE-249: Remove all legacy FreeRDP compatibility.
>
> [mjumper] GUACAMOLE-249: Remove usage of CLRCONV.
>
> [mjumper] GUACAMOLE-249: Comment out remaining usage of SVC.
>
> [mjumper] GUACAMOLE-249: Correct prototypes of glyph handlers.
>
> [mjumper] GUACAMOLE-249: Correct prototypes of pointer handlers.
>
> [mjumper] GUACAMOLE-249: Correct prototypes of GDI handlers.
>
> [mjumper] GUACAMOLE-249: Correct prototype of certificate verification
> callback.
>
> [mjumper] GUACAMOLE-249: Migrate to libwinpr "CF_*" constants for clipboard
>
> [mjumper] GUACAMOLE-249: The freerdp/gdi/gdi.h header is required to access
>
> [mjumper] GUACAMOLE-249: Remove usage of old FreeRDP channels interface.
>
> [mjumper] GUACAMOLE-249: Comment out usage of old event interface.
>
> [mjumper] GUACAMOLE-249: RDP "DisableEncryption" settings flag has been
> inverted
>
> [mjumper] GUACAMOLE-249: Default to negotiated security mode, not old "RDP"
>
> [mjumper] GUACAMOLE-249: Add "nla-ext" option for extended NLA mode.
>
> [mjumper] GUACAMOLE-249: Correct remaining void returns from BOOL handlers.
>
> [mjumper] GUACAMOLE-249: Rely on default bitmap/GDI/pointer handlers for
> all but
>
> [mjumper] GUACAMOLE-249: Correct incorrect syntax introduced by initial
> partial
>
> [mjumper] GUACAMOLE-249: Add missing pixel format parameter to pointer
> image copy.
>
> [mjumper] GUACAMOLE-249: Initialize FreeRDP's GDI implementation (default
> GDI
>
> [mjumper] GUACAMOLE-249: Use reversed byte order for colors locally
> (verification
>
> [mjumper] GUACAMOLE-249: Migrate wait mechanism to event handle interface.
>
> [mjumper] GUACAMOLE-249: Load FreeRDP plugins regardless of entry point
> interface.
>
> [mjumper] GUACAMOLE-249: Centralize handling of connected channels.
>
> [mjumper] GUACAMOLE-249: Use pkg-config to determine location of FreeRDP
> headers.
>
> [mjumper] GUACAMOLE-249: Restore support for CLIPRDR channel.
>
> [mjumper] GUACAMOLE-249: Free GDI implementation. Do not allocate cache
>
> [mjumper] GUACAMOLE-249: Do not include CB_RESPONSE_OK flag in Format List
> PDU.
>
> [mjumper] GUACAMOLE-249: Send Format List Response PDU after successfully
>
> [mjumper] GUACAMOLE-249: Add trace-level logging of received and sent
> CLIPRDR
>
> [mjumper] GUACAMOLE-249: Remove guac_rdp_dvc_list, relying instead on the
> DVC
>
> [mjumper] GUACAMOLE-249: Update RAIL (RemoteApp) support to FreeRDP 2.0.0
> API.
>
> [mjumper] GUACAMOLE-249: Migrate to plugin naming style used by FreeRDP
> 2.0.0.
>
> [mjumper] GUACAMOLE-249: Update Docker build to use FreeRDP 2.0.0.
>
> [mjumper] GUACAMOLE-249: Migrate SVC support to FreeRDP 2.0.0 plugin API.
>
> [mjumper] GUACAMOLE-249: Add example for testing arbitrary SVC support.
>
> [mjumper] GUACAMOLE-249: Migrate loading of RDPSND support ("guacsnd"
> plugin) to
>
> [mjumper] GUACAMOLE-249: Migrate RDPSND support to FreeRDP 2.0.0 plugin
> API.
>
> [mjumper] GUACAMOLE-249: Migrate loading of RDPDR support (guacdr plugin)
> to
>
> [mjumper] GUACAMOLE-249: Migrate RDPDR support to FreeRDP 2.0.0 plugin API.
>
> [mjumper] GUACAMOLE-249: Remove lock around usage of FreeRDP (new library
> appears
>
> [mjumper] GUACAMOLE-249: Gradually reassemble received chunks of RDPSND
> data.
>
> [mjumper] GUACAMOLE-249: Add common SVC plugin implementation as future
> simplified
>
> [mjumper] GUACAMOLE-249: Remove "guacsvc" plugin in favor of leveraging
> common SVC
>
> [mjumper] GUACAMOLE-249: Remove "guacsnd" plugin in favor of leveraging
> common SVC
>
> [mjumper] GUACAMOLE-249: VirtualChannelEntryEx entry point is supposed to
> accept a
>
> [mjumper] GUACAMOLE-249: Dynamically wrap channel entry points (FreeRDP
> will
>
> [mjumper] GUACAMOLE-249: Remove RDP constant definitions which are defined
> within
>
> [mjumper] GUACAMOLE-249: Rename and restructure RDP source files more
> sensibly.
>
> [mjumper] GUACAMOLE-249: Reorganize includes to match code standard.
>
> [mjumper] GUACAMOLE-249: Remove now-unnecessary status.h FreeRDP
> compatibility
>
> [mjumper] GUACAMOLE-249: Callbacks for "drdynvc" plugin should return
>
> [mjumper] GUACAMOLE-249: FreeRDP 2.0.0 requires the Clipboard Capabilities
> PDU to
>
> [mjumper] GUACAMOLE-249: Use correct start location of clipboard buffer
>
> [mjumper] GUACAMOLE-249: Message flags of clipboard data response must be
> set to
>
> [mjumper] GUACAMOLE-249: Remove prototype for
> guac_rdp_bitmap_decompress(), which
>
> [mjumper] GUACAMOLE-249: Correct @file annotations within Doxygen comments
> of
>
> [mjumper] GUACAMOLE-249: Use filesystem constants defined by FreeRDP and
> WinPR
>
> [mjumper] GUACAMOLE-249: Remove unused SEC_TO_UNIX_EPOCH constant.
>
> [mjumper] GUACAMOLE-249: Correct 

Re: Getting an exception in log on connection close

[Mike Jumper]

On Sun, Jan 12, 2020 at 2:31 PM Nick Couchman  wrote:

> On Thu, Jan 2, 2020 at 2:25 AM Umesh Bhatt  wrote:
>
> > Hi,
> >
> > I have custom auth provider and when we close the tab to close a
> > connection I am getting following error in the log.
> > Is there any event which is fired when connection is closed so that I can
> > handle it more gracefully in my auth provider?
> >
> > 12:51:34.973 [Thread-3] DEBUG o.a.g.w.GuacamoleWebSocketTunnelEndpoint -
> > Connection to guacd closed.
> > org.apache.guacamole.GuacamoleConnectionClosedException: Connection to
> > guacd is closed.
> > at org.apache.guacamole.io
> .ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:183)
> > ~[guacamole-common-1.0.0.jar:na]
> > at org.apache.guacamole.io
> .ReaderGuacamoleReader.readInstruction(ReaderGuacamoleReader.java:195)
> > ~[guacamole-common-1.0.0.jar:na]
> > at
> >
> org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81)
> > ~[guacamole-common-1.0.0.jar:na]
> > at
> >
> org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81)
> > ~[guacamole-common-1.0.0.jar:na]
> > at
> >
> org.apache.guacamole.protocol.FilteredGuacamoleReader.read(FilteredGuacamoleReader.java:64)
> > ~[guacamole-common-1.0.0.jar:na]
> > at
> >
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:246)
> > ~[guacamole-common-1.0.0.jar:na]
> > Caused by: java.net.SocketException: Socket closed
> > at
> > java.net.SocketInputStream.read(SocketInputStream.java:204)
> ~[na:1.8.0_232]
> > at
> > java.net.SocketInputStream.read(SocketInputStream.java:141)
> ~[na:1.8.0_232]
> > at
> > sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> ~[na:1.8.0_232]
> > at
> > sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) ~[na:1.8.0_232]
> > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> > ~[na:1.8.0_232]
> > at
> > java.io.InputStreamReader.read(InputStreamReader.java:184)
> ~[na:1.8.0_232]
> > at org.apache.guacamole.io
> .ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:169)
> > ~[guacamole-common-1.0.0.jar:na]
> > ... 5 common frames omitted
> >
> >
> There are some events within Guacamole that deal with tunnel close events,
> but handling that event within your authentication extension is likely not
> going to get rid of these messages.  If you simply close the tab you will
> almost certainly see them.  The only way to avoid this is to have users
> properly "disconnect" from the system before closing the tab.  It's not a
> huge deal either way - it's just Guacamole's way of telling you that it
> detected a close outside of the normal bounds of connection management,
> which can either indicate a problem, or can just be something like this.
>

Yep. The exception is unavoidable, as it's impossible to guarantee that
there aren't packets already on their way to the webapp after the server
has decided to close the connection, nor that everything on the client side
will know that the connection has been closed in time to avoid sending more
data.

Logging of this exception is at the debug level because it's conceivably
useful when debugging, but would likely otherwise cause confusion and isn't
useful under normal circumstances. The presence of the exception isn't an
error, as it's actually already being cleanly handled. All you're seeing
here is additional, debug-level information about the error that was
cleanly handled.

- Mike

Re: rest api docs? and a doubt about the api authentication mechanism ...

[Mike Jumper]

On Wed, Dec 11, 2019 at 7:54 AM Pablo Escobar Lopez <
pablo.escobarlo...@unibas.ch> wrote:

> Hi,
>
> In our team we are doing some tests to interact with the rest api in
> guacamole. Inspecting the traffic with the browser dev tools we found out
> how to create connections and users in guacamole using the api. Our tests
> are accessible here
> https://github.com/pescobar/ansible-playbook-guacamole-api
>
> After our initial testing we have two doubts:
>
> 1) Does anyone has any docs for the api? Anything that  could save us some
> time inspecting the http traffic or the source code would be very helpful
> and appreciated. e.g. I still couldn't find how to get a list of existing
> connections.
>

The current best references are the JavaScript services that use the REST
API. To get the connection hierarchy, you would make a GET request to
.../api/session/data/DATASOURCE/connectionGroups/IDENTIFIER/tree, where
DATASOURCE is the identifier of the authentication provider that you're
retrieving the connections from ("mysql", "postgresql", "ldap", etc.) and
IDENTIFIER is the identifier of the connection group at the base of the
hierarchy being retrieved:

https://github.com/apache/guacamole-client/blob/d1e928bea79ca81c827e9b6adedabc98eefdf701/guacamole/src/main/webapp/app/rest/services/connectionGroupService.js#L36-L79

The identifier "ROOT" can always be used to refer to the root connection
group, regardless of whether the underlying authentication provider calls
it "ROOT".

https://github.com/apache/guacamole-client/blob/7d822df5a3b040bf61d1055fe7bffaf1996c0983/guacamole/src/main/webapp/app/rest/types/ConnectionGroup.js#L111-L117

There is an open pull request adding documentation for the REST API which
is awaiting a response to feedback from initial code review:

https://github.com/apache/guacamole-manual/pull/123

That said, I expect there is a better approach than adding manually-written
docs to the manual, given that the REST services are already documented at
both the Java and JavaScript levels. There should be some tool out there
which can generate JavaDoc-esque documentation from that, perhaps with
minor changes, annotations, etc. to the existing comments.


> 2) We did a test with a guacamole instance using OpenID auth (
> https://guacamole.apache.org/doc/gug/openid-auth.html) and 2FA and we
> could
> authenticate with the api using a local guacamole admin account. I mean, if
> I access guacamole with a browser I have to use EduID+2FA but our ansible
> code can "bypass" it and authenticate with the api using the local
> guacamole account. For us it's convenient because we can use the api even
> with EduID+2FA enabled but I am not sure if this is a bug or a feature. Is
> it the expected behavior?


Yes, definitely not a bug. This is intentional. Guacamole will always
attempt to authenticate the user using all installed extensions, in order.
Once one extension authenticates the user, other extensions are then
allowed to provide data for that user, trusting the authentication result
of the other extension. If you have both OpenID and a database extension
installed, then users will be able to authenticate using OpenID or (if they
have a password set in the database) the database.

There are 2FA extensions which are part of guacamole-client (the Duo and
TOTP support) which will veto the authentication result of other extensions
and enforce multi-factor. That won't happen if the multifactor auth is
happening on the OpenID side, outside of Guacamole's view.

- Mike

Re: Some issues and questions regarding RDP file transfer

[Mike Jumper]

On Tue, Nov 19, 2019 at 8:50 AM gabriel sztejnworcel 
wrote:

> Hi,
>
> We would like to start using RDP file transfer. We found some issues I
> would like to discuss:
>
> 1. After uploading 64 files in one session (not on the same time), the next
> uploads fail with an "Invalid stream index" error. I found that the max
> stream index is 64, and the client holds a pool of stream indices for the
> uploads. The problem is that it does not mark an index as free when an
> upload finishes. There is a function that does this - endStream(), but it's
> not called (the function also sends an "end" instruction which I don't
> think is relevant in this case).


It's called by sendEnd() in Guacamole.OutputStream and is critical for
streams that are managed by the JavaScript client (not streams intercepted
by the webapp - see below):

https://github.com/apache/guacamole-client/blob/062edda07b7759d3a86a9a8b476d03eb8a4aeda1/guacamole-common-js/src/main/webapp/modules/OutputStream.js#L61-L66

The "end" instruction is also critical. The server needs to be informed
when the stream is ending so it can free resources, take any actions
required by the underlying remote desktop protocol when transfers are
completed, etc. When a client-side stream is not used within JavaScript,
but is intercepted within the webapp (used by the mainline Guacamole
webapp), it would be on the webapp to send this instruction on behalf of
the user, as is done here:

https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/tunnel/InputStreamInterceptingFilter.java#L82-L92
https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/tunnel/InputStreamInterceptingFilter.java#L112-L121

We solved this in our repo by freeing the index when receiving the
> "loadend" event from the upload ajax call.


What version of Guacamole are you using?

Is this a known issue?
>

No.


> 2. Uploading more than 64 on the same time is not possible due to the max
> streams limit. We would like to solve it by creating a queue of pending
> file uploads on the client side. Does this make sense?
>

Yes.

3. The following scenario:
>
> a. Connect to an end point using Guacamole with drive redirection.
> b. Assign a drive letter to the redirected drive/folder.
> c. MSTSC to another machine with drive redirection.
> d. The Guacamole redirected folder appears on the second machine and
> uploaded files can be accessed, but when we delete a file (from within the
> nested RDP session), the file is not deleted. It disappears from file
> explorer, but appears again upon refresh. It is not deleted from the
> Guacamole machine. We reproduced the issue on Windows Server 2012 R2 and
> Windows Server 2016 targets (for the nested RDP session), on Windows Server
> 2008 R2 it didn't reproduce, delete worked as expected.
>
> Any ideas on what can be the reason for this behavior? I know it seems like
> an esoteric use case, but it's actually our main flow so it's important for
> us to solve it.


I'm not sure what could cause this. The first step would be to confirm that
the issue is specific to Guacamole by trying the same through MSTSC. If
this is confirmed, then it may be that there are filesystem operations that
MSTSC depends on for drive forwarding but which are not implemented. The
logs from guacd may help.

Why not connect using Guacamole directly to the machines in question,
rather than nest things?

- Mike

Re: Error de script Debian 10 buster

[Mike Jumper]

On Sun, Sep 15, 2019 at 6:10 AM Alain UBFC  wrote:

> Good morning, everyone,
> ...
> Here is the error:
>
> guacenc.c:79:5: error:'avcodec_register_all' is
> deprecated[-Werror=deprecated-declarations]
>   avcodec_register_all();
>   ^~~~
> In file included from guacenc.c:27:
> /usr/include/x86_64-linux-gnu/libavcodec/avcodec.h:4102:6: note:
> declared here
>   void avcodec_register_all(void);
>^~~~
> cc1: all warnings being treated as errors
> make[2]: *** [Makefile:761: guacenc-guacencenc.o] Error 1
> make[2] : we leave the directory "
> /opt/guacamole-server-1.0.0.0/src/guacenc ".
> make[1]: *** [Makefile:510: all-recursive] Error 1
> make[1] : we leave the directory " /opt/guacamole-server-1.0.0.0 ".
> make: *** [Makefile:432: all] Error 2
>
>
> Do you have any idea how to remove this error?
>

Disable the guacenc portion of the build with the configure script's
"--disable-guacenc" option, build from git, or await the 1.1.0 release in
which this is fixed.

See: https://issues.apache.org/jira/browse/GUACAMOLE-638

- Mike

[DISCUSS] Support for proprietary libraries

[Mike Jumper]

Hello all,

Some time ago, I was tasked at my day job with adding support for the
RealVNC SDK as an alternative to libvncclient. This was not due to some
inherent advantage of that SDK, but due to a proprietary encryption scheme
required by some RealVNC servers which only their SDK implements.

I was able to do this through abstracting away the VNC backend, letting the
build process select between the two. It does work, but I immediately ran
into problems which lead me to believe it wouldn't be acceptable here
(upstream):

1) The RealVNC library lacks callbacks which expose the nature of updates
received, including whether the mouse cursor has changed or whether
CopyRect is used. This means VNC support using the SDK will always be
slower than libvncclient, and there is effectively no local mouse cursor
(only remote).

2) Licensing of the SDK is such that I'm unsure what would be required for
people to build against it as part of normal development, including CI via
the ASF Jenkins.

3) The SDK will not allow direct TCP connections at all unless a special
"add-on code" is purchased to activate that rather fundamental feature.

So ... on one hand, some may appreciate the support if they are in the
position where they are forced to use the SDK because of the proprietary
encryption. On the other hand, building against the SDK produces VNC
support which will not perform as well, may be tricky to arrange for
general testing and CI, and requires an "add-on code" in order to be useful
even if you have the SDK.

Thoughts?

- Mike

Availability of JIRA filters, boards, etc. for committers

[Mike Jumper]

Hello all,

I've been using a private JIRA dashboard and set of filters as a means of
tracking what I'm working on and release status. As I now have permission
in JIRA to share dashboards/filters and to create boards, I've shared
everything to the "committers" role on the project.

Committers should now have access to:

* A general dashboard which shows release status, assigned issues, and
outstanding issues:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328417

* A kanban board for tracking the status of the next Apache Guacamole
release:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=336=true

- Mike